Здравствуйте, PSV100, Вы писали:
PSV>Создаётся чистый HTML (пусть верстальщиком, дизайнером), без шаблонов, без CSS-элементов, без никакого кода, где есть некоторые правила, например, условные имена для div. Программист в коде читает этот файл, он трансформируется в структуры и пр. этого языка, дальше манипулируй с документом как хочешь в рамках программного кода.
Я бы не сказал что это хороший подход.
ИМХО тут слишком много не нужной работы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
view HelloView(model : HelloModel)
{
<p>First name: <input value <-> model.firstName; /></p>
<p>Last name: <input value <-> model.lastName; /></p>
<h2>Hello, <span text <- model.fullName; />!</h2>
}
Вот скажем тут свойство fullName будет вычислино при создании объекта модели.
При этом после каждого изменения свойств firstName или lastName оно будет пересчитано.
В данном случае эти свойста связываются с текстовым полем. И после каждого изменения текстого поля будут обновляться.
После чего обновиться fullName. После обновления fullName система поймет, что нудно обновить тег <span text <- model.fullName; />.
Можешь собрать https://github.com/rsdn/nemerle/tree/master/snippets/Nemerle.WUI.Reactive и посмотреть, как это работает.
S>1. Зависимые контролы. Типа выбор радиобаттона определяет видимость или разблокированность связанных с ним контролов. Очевидно, решается введением зависимых свойств. Типа, BillingAddressPanel.Enabled = !BillingIsTheSameAsShipping.Checked
Чекбокса? Но не важно.
Тут мы вводим в ViewModel свойство BillingIsTheSameAsShipping. После чего связываем его с чекбоксом и с показом контролов.
S>2. Валидация данных, с отображением результата валидации. Вариантов оформления — бездна. Суть — более-менее одна: есть некая формула, которая связывает данные с результатом валидации, а результат валидации — с внешним видом контролов. Опять — таки зависимые свойства.
Ту тоже все просто. В ViewModel заводим коллекцию, в которую записываем ошибки валидации.
Благодаря реактивности валидация будет производится автоматом.
Все что нам останется это сделать отображение коллекции ошибок в ГУИ.
S>3. Нетривиальное поведение. Скажем, вводим URL — по окончанию ввода в фоне программа бежит по этой ссылке и отображает preview картинки или что там по этому URL нашлось (см.тж. facebook). S>Тут нюанс в том, что надо вешаться не каждое изменение данных, а только на более-менее паузы. S>В Delphi мы такие штуки делали путём добавления отдельного объекта-таймера и довольно муторной обработки событий OnChanged и OnTimer.
Тут нужно подумать.
Как вариант можно захардкодить режим обновления не после каждого изменения, а после некоторой паузы.
Но способ произвольно фильтровать события тоже нужен. Нужно подумать над красивым решением.
S>4. Аналогичная штука — анимации.
Тут нужен язык описания анимации.
И так как я это ни разу не делал у меня маловато информации, чтобы сходу спроектировать язык.
Могу только пофантазировать на тему того что нам нужны кейфреймы и способ плавного перехода от одного кейфрейма к другому.
Или нужно что-то еще?
Короче нужно садиться и описать то, что нужно.
S>Не обязательно визуальным — важно обойтись без лишнего мусора, типа асинхронных таймеров и синхронных стейт-машин, описанных вручную.
Это не сложно. Переписать линейный код в асинхронный автомат задача тривиальная.
Я такое уже делал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, oldjackal, Вы писали:
O>Здравствуйте, gandjustas, Вы писали:
G>>>>Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL. O>>> Это не так. G>>Покажи на примере чтоли? O> Давайте задачу — покажу, как хреноватый кодер (я, то есть), не приходя в сознание под эту задачу dsl делает.
Я уже говорил — разработка сайтов.
O>>> PHP. Серьезно. G>>PHP — язык общего назначения. O> А мы теперь только не-Тьюринг-полные языки будем за dsl считать? Я так не играю.
Я таки думаю что за DSL нужно считать именно domain-specific. То есть яызки которые имеют ярко выраженную предметную область и имеют некоторые средства, недоступные в этой области ЯОН.
В PHP нету ничего специального для работы с HTML или HTTP. А вот если razor взять, то очень даже есть. Поэтому первый — яон, а второй DSL.
Здравствуйте, Sinclair, Вы писали:
S>Странно. Вот вы не видите смысла, тем не менее даже ваша система использует этот отдельный язык. Как так?
Эм, ну допустим в следующей версии редактор перейдёт с xml файла на sqlite базу данных. Это изменение же абсолютно не изменит работу с самим редактором. Т.е. не поменяется вообще ничего — в моём понимание это значит что у нас там не язык а просто средство сереализации, типа базы данных. Но вообще это просто вопрос терминологии, так что наверное спорить тут глупо. Надо просто договориться что как называем и всё. )
S>Это интересная идея. У меня есть некоторые подозрения о причинах отсутствия таких DSL, но я в них совершенно не уверен. S>Если хотите, можем пообсуждать возможности и трудности, связанные с созданием такого DSL.
Было бы интересно. Хотя могу сразу сказать что я в dsl строение не специалист — ни одного не создал пока что. А вот в их использование на оборот. Обычно у нас каждый проект использует десяток разных языков/технологий.
Значит сформулирую пожелания к подобному GUI DSL. Хотелость бы удобную размётку документа (кстати, желательно с визуальным редактором, но это отдельный вопрос) с возможностью указывать в виде обработчиков не только функции из системного языка, но и вызов некоторого набора функций GUI объектов.
Ну и первая мысль для обсуждения: html+javascript в какой-то степени реализуют подобную модель. Но с парой поправок:
1. там это всё не особо удобно на самом деле
2. подобную практику (javascript внутри например OnClick) в данный момент считают плохой. И понятно почему — в данном случае javascript играет роль не gui dsl, а системного языка. Т.е. писать такой код, это по аналогии что-то типа вставки c++ кода в *.rc файлы. )))
Но в приципе, технически, в html+javascript подобный gui dsl реализуем.
Здравствуйте, Sinclair, Вы писали:
S>Никакого бреда. Представьте себе, что у вас два девелопера чинят два бага. Один увеличивает ширину кнопки submit, потому что в мадагаскарской локализации не влезла надпись, а другой меняет порядок табов на экране. S>Теперь у них конфликт обновлений, и нужно выполнить слияние изменений. Если формат текстовый, но содержит произвольно изменяемые фрагменты типа автогенерённых идентификаторов объектов (см. например файлы Rational Rose), или вообще не дай байт бинарный, то это слияние будет делать крайне неудобно. (Ну, разве что вы разработаете свой специальный инструмент для этого, типа как в Microsoft Word). А если ваш язык проектировался как человекочитаемый, то с большой вероятностью существующие инструменты прекрасно подойдут. Разработчику будет совершенно очевидна суть сделанных изменений. S>Не нужно думать, что эта задача требует каких-то сверхъестественных усилий. Посмотрите на то, как выглядят DFM-файлы в текстовом режиме. А ведь они пригодны для описания более-менее произвольной разметки контролов, в том числе и расширяемой.
Ммм, ну да, должен признать что регулярно вижу диффы этих файлов в Mercurial и по ним даже можно понять что поменяли люди. Но я как-то никогда не воспринимал это как существенное преимущество. ) И слияние на таком файле автоматике старались никогда не доверять. )))
_>>Тут основной поинт был не в том что мышкой. А в том что мы по сути пользуемся DSL но при этом никто не продумывал для него синтаксис и т.п. не самые тривиальные детали. S>Ну как это не продумывал? Конечно же продумывали. Вот этот ваш "визуальный синтаксис" — он же существует! Как-то показаны взаимоотношения контролов — иерархия, сцеплённость, размеры, и другие характерные вещи, которые вы редактируете. То, что вы не выделяли отельную фазу "разработка синтаксиса языка", ничего не значит. По факту он есть, пусть и в виде результата множества мелких решений.
Ммм, ну это скорее задано самим фреймворком, под который генерируется код, а не авторами редактора. Вообще к чему это всё я говорю. Вот я смотрю на этот редактор и в общем не вижу никаких проблем написать самому такой же вообще практические не думая. Т.е. тупо "закодить". А вот если бы я захотел придумать некий язык, по которому потом генерировался тот же код, то я бы с самого начала начал задумываться над всякими нюансами. Причём не обязательно какими-то "высоконаучными", а возможно просто стилевыми. Например использовать мне в моём dsl {} или begin/end? Я не говорю что это что-то дико сложное, но всё же время отнимает. А в случае с редактором ничего такого нет — тупо закодить визуальный редактор плюс набор шаблонов кода под контролы.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Хвост, Вы писали:
Х>>и как, много ты уже моделей видел на практике? их по сути три: абстрактная машина, реляционная модель, редко но метко лямбда-исчисления. совсем редко всякий экстрим вроде пролога можно не рассматривать. Так вот, для покрывания подавляющей потребности в твоих дслях с моделями вычислений достаточно взять гибридный язык с поддержкой рефлексивной метаинформации рантаймом, например скалу или фшарп и усё, все модели как на ладони. ДСЛ не нужен! WH>Ты даже не представляешь насколько ты смешон. WH>The principal programming paradigms
WH>Это только для языков общего назначения. И там еще не все перечислено.
спасибо кэп, только где в этой картинке противоречие с моими словами? вся твоя картинка вписывается в те самые три модели, за исключением xml,html и прочих markup-языков, у которых вычислительной модели нет. Тот же хаскель позволяет описать декларативно вещи подобные channels в го, или императив BASIC, или sql-like конструкции для обращения к коллекциям.
WH>Но есть и более конкретные языки. Например, этот https://github.com/rampelstinskin/ParserGenerator имеет свою ни на что не похожую модель вычислений.
Ни на что ни похожая модель вычислений это уже подозрительно, а точнее такого не бывает. Можешь вкратце рассказать что там?
Здравствуйте, WolfHound, Вы писали:
WH>Мой вариант такого ДСЛ основан на MVVM. WH>Model это произвольный код, не имеющий к ГУИ отношения. WH>ViewModel основана на реактивном программировании. Те если внутри ViewModel что-то изменилось, то все что на основе этого было вычислено также автоматические пересчитывается. WH>View это маппинг ViewModel на контролы. Благодаря реактивности при любом изменении ViewModel View автоматически пересчитывается. Также View может менять ViewModel при помощи биндинга свойств контролов на свойства ViewModel.
Интересно. Как я понимаю для model подразумевается использовать какой-то системный язык, для view что-то типа языка размётки, а для viewmodel как раз тот самый dsl?
Или же можно ещё всё писать например на системном языке. Тогда model — это просто код. view model может быть что-то типа dsl внутри языка (типа как boost.sprit), а view может быть кодом генерируемым редактором.
Кстати, а все эти мысли — это вот только рассуждения в этой теме или может уже что-то реальное? Vlad2 вот кидал ссылку на что-то из этой области, но там веб-фреймворк обсуждался...
Здравствуйте, Sinclair, Вы писали:
S>3. Нетривиальное поведение. Скажем, вводим URL — по окончанию ввода в фоне программа бежит по этой ссылке и отображает preview картинки или что там по этому URL нашлось (см.тж. facebook). S>Тут нюанс в том, что надо вешаться не каждое изменение данных, а только на более-менее паузы. S>4. Аналогичная штука — анимации.
Это по сути один пункт — настройка поведения UI. Решается он путем позволения разработки своих контролов и связываний (биндингов). А так же возможность вмешаться в ход работы реактивной модели и что-то похимичить.
Здравствуйте, Sinclair, Вы писали:
A>>давайте разберем такой проект — надо написать IM клиент, например для jabber'а A>>допустим у нас нет готовой библиотеки и мы пишем его с нуля A>>у него есть UI, несколько слоев сетевого кода, куча мелких модулей типа конфига и т.п. A>>где там можно применить DSL? S>Например, шибко бы пригодился DSL для описания протокола взаимодействия, чтобы чётко были видны все переходы статусов соединения.
Здравствуйте, alex_public, Вы писали:
_>Интересно. Как я понимаю для model подразумевается использовать какой-то системный язык,
Да что угодно.
_> для view что-то типа языка размётки,
Скорее что-то типа XSLT для трансформации ViewModel во View.
_>а для viewmodel как раз тот самый dsl?
Да. Но все что ему нужно это поддержка реактивности. Те пересчет всего что зависит от того что поменялось.
_>Или же можно ещё всё писать например на системном языке. Тогда model — это просто код. view model может быть что-то типа dsl внутри языка (типа как boost.sprit), а view может быть кодом генерируемым редактором.
Не взлетит.
_>Кстати, а все эти мысли — это вот только рассуждения в этой теме или может уже что-то реальное? Vlad2 вот кидал ссылку на что-то из этой области, но там веб-фреймворк обсуждался...
Я кидал. И я разу сказал, что это легко обобщить на любой ГУИ.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Уууу какое сообщение. )
PSV>Ты вроде раньше говорил, что разработка у тебя под виндой и используется (или теперь уже использовалась) студия. Гуй, я так понимаю, какой-то свой, но по идеологии что-то напоминает MFC. Я уже смутно помню, какое там было взаимоотношение дизайнеров с их местными картами сообщений, но такие мотивы песен вроде тебя не устраивают. Среди промышленных систем Delphi умеет делать то, что ты хочешь, со времён царя гороха. Там кроме визуальных контролов/виджетов есть и невизуальные компоненты, которыми тоже можно манипулировать в дизайнере. В нашем случае это так называемые там Action-ы: програмляются типовые объекты, которые реализуют нужные универсальные действия, затем эти action-ы в дизайнере привязал к нужным кнопкам и меню и т.д. Из коробки есть много чего типового, фактически, для учебного примера можно только в дизайнере наваять полноценный редактор по типу блокнота, не написав ни строчки кода (хотя, скорее всего, я несколько преувеличиваю, но не много). А если к такой системе прикрутить тот ДРАКОН, о котором мы недавно говорили — получи полноценную, и реально мощную, графическую систему программирования.
Не знал что Дельфи такая модная в этом смысле. ) Мы то её никогда не использовали по своми причинам и видимо никогда не будем. Но возможно что часть идей оттуда хорошо бы стащить. )))
PSV>А вообще-то, я тебе как-то говорил про нашу DSL-систему. У нас там есть фактически встроенная мини-дельфи. Но со временем у нас развился альтернативный скриптовый язык (кроме встроенного Паскаля), и для наших (!) многих задач мы убедились, что эффективнее всё-таки вручную програмлять интерфейс, особенно, если язык, простой и эффективный, позволяет несложно это делать. Как-то это гибче, мощнее, особенно когда нужно реализовать сотни типовых форм. Но и GUI-дизайнер тоже для ряда случаев удобная вещь.
Если свой dsl то тут без вопросов понятно что он удобнее. Визуальный редактор то прикручен к некому универсальному...
PSV>Здесь рядом в своём сообщении WolfHound говорит о реактивном программировании на основе model-view. Вполне здравая идея, проверенная у нас. Удобно, когда подправил скрипт и сразу видишь результат неотходя от кассы, часто не нужны отладчики или debug-сообщения.
Интересно, есть ли рабочий пример такого подхода? В смысле не какая-то конкретная реализация типа вашей, а как универсальный фреймворк.
PSV>И языки разметки, имхо, на помойку лучше не выбрасывать пока, их неплохо можно готовить несколько по другим рецептам. Вот представь, что ты делаешь ГУИ на основе какого-нибудь HTMLLayout. Здесь есть отличный шанс на разделение задач: HTML — это структура, основа, документа, CSS — оформление (возможен не один вариант). При этом, какие-то верстальщики формируют HTML, они для этого могут сами для себя воспользоваться ещё одним DSL, например, Haml, какие-то дизайнеры возятся с CSS, могут для себя использовать Sass — ещё один DSL. Внутри HTML можно указать ещё DSL — шаблон для формирования документа. Лично мне симпатичны шаблоны без встроенного кода, как CTemplate от Google, или по мотивам Mustache ( {{переменная}}, {{! комментарий }}, {{#секция}} — {{/секция}}).
Ну я говорил всего лишь что если у нас в языке только размётка, то частенько мне сам язык и видеть не надо — пускай им визуальный редактор занимается.
PSV>А вообще-то, лично я с вебом слабо повязан, но я заметил хороший подход в некоторых фреймворках на Кложуре (возможно это сплошь и рядом, я не в курсе, но что-то сильно не заметно). Создаётся чистый HTML (пусть верстальщиком, дизайнером), без шаблонов, без CSS-элементов, без никакого кода, где есть некоторые правила, например, условные имена для div. Программист в коде читает этот файл, он трансформируется в структуры и пр. этого языка, дальше манипулируй с документом как хочешь в рамках программного кода. Также можно работать с CSS. Можно с нуля всё запрограмлять. Можно обработчики событий назначить, при этом можно код писать в самой Кложуре, вроде есть компиляция в JavaScript.
Да, это сейчас стандартный подход для javascript вроде при хорошем стиле. Всяческие jquery даже делают работу с этим всем удобным.
PSV>Имхо, отличный подход, который можно взять на вооружение не только для веба.
Ну вообще то например древние rc файлы тоже действовали по такому принципу. Т.е. там были только id, к которым потом обращался код. Правда не было разделения на структуру (html) и стили (css), но это уже мелочи. И я бы не сказал что из этого вышел очень удачный инструмент. Хотя для своего времени...
Здравствуйте, alex_public, Вы писали:
VD>>Да ладно. Кодокенерация у них встречается частенько. Для тех же ресурсов дотнета они генерируют классы-обертки.
_>Угу, это ещё в MFC было — ClassWizard и т.п. И помнится там был ещё генератор обёрток для COM. Но это именно пустые классы, а вот код с какой-то логикой работы... Такого не помню у них ни разу.
Ты запутался. Я не говорил о визардах. Я говорил о генерации кода. МС довольно плотно его применяет. Для тех же ресурсных файлов дотнета генерируется класс который обеспечивает типизированную обертку для этих ресурсов. Скажем если ты добавил в ресурсы число и дал ему некое имя, то в классе ресурсов появится свойство типа int.
В студию даже входит простенькая утилитка для герерации текста — T4. И есть даже проект — Oslo. Который, правда, похоже замаскировали (скрыли от глаз).
VD>>Вопрос только в катастрофически низком уровне этой генерации.
_>Вот мне не понятно почему оно у них тут низкое, для такой простой задачи.
Где ты увидел простую задачу? Еще раз. Речь не идет об одноразовой генерации вроде того что делают визарды.
_>Да, само собой это какая-то разновидность dsl. Но при этом без создания синтаксиса языка. Может это не плохое решение, пока нет удобных автоматических инструментов dsl-строения? )
Это самообман. Синтаксис вы все равно создаете. Просто он уродливый, так как выражается через возможности хост-языка. Это, скорее всего, набор классов и иерархия объектов.
У МС — это CodeDome. Это уродливый и кривой ДСЛ описывающий состояние контролов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Давайте обсудим примеры каких-нибудь конкретных gui-сценариев, где "в классике" нам нужно писать обработчики событий, от которых хочется уйти. S>...
Что-то это какой-то уход в мелкие детали. Я бы начал с простой общей вещи. Что в нашем языке есть какое-то отображение понятика контрол — в какой-то объект языка. И эти объекты мы в языке можем создавать и потом вызывать их функции. И отдельно можем вызывать функции "системного" языка. В принципе уже только это позволило бы убрать практически весь код связанный с интерфейсом в наш dsl, оставив системному языку только "движок".
Здравствуйте, netch80, Вы писали:
N>Некоторые тезисы к обсуждению...
Буду краток — полный бред. Подменил понятие "ДСЛ" на понятие "Уровень языка", и выстроил на этом стройную, но бессмысленную картину. Выводы в конце вообще из пальца высосаны. За одно к "немерлистам" записал пол форума. Синклер такой прям рьяный немерлист .
Но пока читал все это сформулировал для себя очень простой критерий выявления ДСЛ-ей. ДСЛ не позволяет воспроизвети себя же, если это не ДСЛ описания компилятора.
На то она и предметная область, чтобы решать только ее задачу. Если ДСЛ позволяет (пусть криво или медленно) воспроизвести себя, то это ЯОН (язык общего назначения). А его уровень не имеет никакого отношения к ДСЛ-ности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Где ты увидел простую задачу? Еще раз. Речь не идет об одноразовой генерации вроде того что делают визарды.
А зачем?
VD>Это самообман. Синтаксис вы все равно создаете. Просто он уродливый, так как выражается через возможности хост-языка. Это, скорее всего, набор классов и иерархия объектов.
Только его создают не авторы редактора, а авторы фреймворка. )
Здравствуйте, WolfHound, Вы писали:
_>>Или же можно ещё всё писать например на системном языке. Тогда model — это просто код. view model может быть что-то типа dsl внутри языка (типа как boost.sprit), а view может быть кодом генерируемым редактором. WH>Не взлетит.
Почему? )
_>>Кстати, а все эти мысли — это вот только рассуждения в этой теме или может уже что-то реальное? Vlad2 вот кидал ссылку на что-то из этой области, но там веб-фреймворк обсуждался... WH>Я кидал. И я разу сказал, что это легко обобщить на любой ГУИ.
Ой, сорри, точно. И ещё же говорили про это. Это я просто запутался прочитав там сообщения некоторые)
Не знаю насколько легко обобщить... Для меня не очевидно пока. Вообще html+javascrip — это как бы лёгкая область для экспериментов мне кажется. Когда мы переходим к компилируемым типизированным языкам и сложным нативным контролам, то уже не так очевидно всё выглядит.
Здравствуйте, VladD2, Вы писали:
VD>На то она и предметная область, чтобы решать только ее задачу. Если ДСЛ позволяет (пусть криво или медленно) воспроизвести себя, то это ЯОН (язык общего назначения). А его уровень не имеет никакого отношения к ДСЛ-ности.
Плохой критерий.
Ибо так умеют все полные по Тьюрингу языки.
Соответственно если вдруг ДСЛ окажется полным по Тьюрингу, то он сразу перестает быть ДСЛ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>А раз мы привязываемся к некоторому домену то для любого языка можно придумать домен (а обычно множество доменов) для которых данный язык является языком предельно высокого уровня. Те делай, что хочешь, но язык более высокого уровня не придумать. Ибо язык и так напрямую оперирует терминами предметной области.
Это бессмысленное философствование превращающее в бессмыслицу даже заголовок данной темы.
Ты договорился до того, что ЯОН вообще нет в природе (а он есть (с) анекдот про суслика).
Уровень ЯОН не делает из него более ДСЛ для всех задачей.
Конечно всегда можно придумать ДСЛ который будет решать задачу одним оператором. Типа "Реши мне мою проблему". Но он опять таки на фиг ни кому не упал, так как для каждой задачи придется делать новую реализацию такого ДСЛ-я. И это будет сложение лобового решения.
Создание ДСЛ не будет бесплатным никогда! Ни какие N256 не устранят необходимости выделять модель, придумывать язык для ее описания и манипуляций с ней, реализовывать язык и т.п.
Все что можно сделать сократить затраты на такую разработку. Но все равно будет сто тысяч задач которые проще решить в лоб, нежели писать для нее ДСЛ в стиле "Решим мне мою проблему".
Конечно можно порассуждать на тему, что для таких задач ДСЛ-ем является ЯОН или вообще ассемблер. Но от таких рассуждений толку еще меньше.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>>>Как зачем? Чтобы выполнять задачи управления данными в БД. V>>Я непонимаю. Есть проблемы поважнее баз данных, которым совершенно не нужны такие раздутые "прямые обращения", а нужно просто хранение массивов данных в иерархии и быстрый доступ к ним. S>Если вам нужно "просто хранение массивов данных в иерархии и быстрый доступ к ним", то вам не нужен ни SQL, ни заменяемая им равномощная библиотека.
Ну тогда и язык мне не нужен, можно всё на бумаге считать.
Речь то как раз про удобные и несложные средства. SQL на них не тянет, т.к. является таким же тяжёлым языком как языки общего назначения.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Gaperton, Вы писали:
G>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.
Это очень спорное утверждение.
Квалификация может требоваться и очень высокая, а вот решение будет более простым для достаточно квалифицированного специалиста.
Возьмем, опять же, в пример грамматики и генераторы парсеров. Человек с недостаточной квалификацией не получит никаких выгод от супер-пупер-крутого генератора парсеров, так как банально не сможет разобраться с описанием грамматики. Но человек с достаточной квалификацией реализует парсер с помощью этого генератора куда быстрее и проще, чем без него.
Так что цель создания ДСЛ — упростить решение задачи. А рассуждения про квалификацию здесь излишние (если не сказать некорректны).
G>Еще один пример
А где был первый пример?
G>из обыденной практики — использование LUA для написания скриптов AI в играх. Их пишут не программисты.
Это сказка. Их пишут программисты. Возможно специализированные прикладники, но программисты. Не программисты тупо ничего работающего не могут написать.
G> Это для них в игровую платформу внедряют LUA. Цель — исключить необходимость затратного общения между гейм-аналитиками и программистами при реализации AI, пусть аналитики справляются сами.
Луа — ЯОН. Весь смысл его применения в игровых движках — сделать их отладку более интерактивной.
Ну, и никакие аналитики им пользоваться не могут. Да и что за зверь такой этот аналитик? Может дизайнер уровней?
G>Поэтому, все действительно практически успешные DSL на текущий момент имеют в качестве базы простейшие языки, с семантикой не сложнее раннего бейсика. 1С только один из немногих примеров.
Подмена предмета обсуждения дететкетд. Луа — ЯОН. Все выводы сделанные на предположении, что Луа — это ДСЛ ничтожны.
Ну, и 5 копеек про "с семантикой не сложнее раннего бейсика":
Класс языка:
мультипарадигмальный:
скриптовый,
императивный,
функциональный,
объектно-ориентированный (прототипный)
(с) Википедия.
Ничё так описание для языка не сложнее раннего бэйсика. Так и вижу себе реализацию GoSub на мета-таблицах.
G>Еще примеры? Системы компьютерной алгебры. Maltab. Maple.
Отличные примеры! Как нельзя лучше демонстрируют, что для решения задач через него должна требоваться квалификация на порядок большая, чем у обычного программиста. Только не в программировании, а в предметной области.
G>Автокад, который перешел с автолиспа на VBA. Язык TradingStation для описания торговых роботов.
Ага. И видимо после перехода с Лиспа на ВБА скрипты чудесным образом превратились в ДСЛ.
Там что Лисп, что ВБА используются для автоматизации. А сами языки универсальны в доску.
G>И это закономерно, что базовая семантика этих языков тупа до безобразия.
Чё за базовая семантика такая? Чем она у Лиспа острее? Его семантику можно на любом языке за денек воспроизвест\и.
G>Влад, ты в каком-то своем странном мире живешь, реально.
Влад, ты в каком-то своем странном мире живешь, реально.
VD>>1Эс — это ЯОН + среда ориентированная на бизнес-задачи. Того же самого можно было бы добиться создав библиотеки и внешние утилиты для явы или дотнета.
G>Не думал, что когда-либо это скажу. Но. "Сперва добейся" (с)
Что добиться то? Там основные заслуги в организации франчейзи, сети сбыта, маркетинге и т.п. Как программный продукт 1Эс скорее всего уступит какому-нибудь Парусу с огромным счетом.
И на хрена мне этого добиваться то? У меня свои "игрушки".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
