Здравствуйте, Ikemefula, Вы писали:
I>Чем он хорош ? Для таких вещей нужна максмальна прозрачность, клик мышом и сразу видишь, что как делается а при желании там же можно и подебажить системный код. I>Ты думаешь, если апи у микрософта кривой, то обложив его картинками, он станет лучше ? Вот тебе задачка — твой ДСЛ очень классно работает, но вот засада, на одном из серверов в продакше отваливается и урлы не мапятся. I>Без ДСЛ нужно воспроизвести ситуацию и тупо продебажить. Что ты будешь делать с ДСЛ ?
С ДСЛ-ем тебе просто должно быть выдано корректное (объясняющее причину ошибки) сообщение или хотя бы исключение.
Если это не так, то — это ошибка в ДСЛ-е. Значит задача сводится к отладке ДСЛ-я. Тут как бы те же методы отладки, что и с библиотеками.
I>Я понимаю, у вас немерлистов хроническая болезнь — при объяснении спрыгивать на свои частные задачки, но это ваши проблемы.
Он такой же немерлист как ты. Год назад так же возражал на форумах. Потом надоело и он попробовал.
Насколько я знаю он сейчас во всю на Руби работает. Да и Шарп вроде как во всю использует.
I>см выше. Правильный пример вот такой — берем бизнес-логику, ну что бы далеко не ходить, из примера AVK. Предложи ДСЛ.
I>http://rsdn.ru/forum/philosophy/4701734.1.aspx
Здравствуйте, Wolverrum, Вы писали:
W>Я бы придерживался все же конкретных дефиниций (хотя бы на основе той же ру.кипедии), а не всевозможных IMHO. типа Владовских либо твоих.
Где ты в википедии видел другие определения? Ты их просто по своему интерпретируешь.
Да и смотреть на русскую википедию я бы не стал. В английской обычно все более точно описывается. Уж больно слабый контроль за русской ее частью.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
I>>Без ДСЛ нужно воспроизвести ситуацию и тупо продебажить. Что ты будешь делать с ДСЛ ?
VD>С ДСЛ-ем тебе просто должно быть выдано корректное (объясняющее причину ошибки) сообщение или хотя бы исключение.
Ничего он не выдаст, поскольку проблема в асп и иис, а исключений в том случае про который я говорю, нет и не будет. Потому ДСЛ только затруднит отладку.
I>>см выше. Правильный пример вот такой — берем бизнес-логику, ну что бы далеко не ходить, из примера AVK. Предложи ДСЛ. I>>http://rsdn.ru/forum/philosophy/4701734.1.aspx
Здравствуйте, VladD2, Вы писали:
VD>ДСЛ не ЯОН. По тому отлаживать его обычно сильно проще. Плюс можно натягивать отладочную информацию на ДСЛ. Думаю, что мы предоставим средства и для этого. Например, при генерации кода можно позволить задавать привязку к синтаксическим конструкциям ДСЛ-я следующим образом:
ЯОН не ЯОН, но если ДСЛ используется для императивных действий (а не как описание модели данных), то без дебага не обойтись. Отладочная информация — это один вариант. Но необходима формализация и обобщение такой инфы, чтоб юзер мог расширять. Минус отладочной информации — мы получаем два вида генеренного кода: с отладочной инфой и без. Иногда надо дебажить код без отладочной инфы.
К сожаленью, в реальности будет смешение ДСЛ и ЯОН а потому надо уметь дежить код, в котором часть сгенерена а часть рукописна.
VD>Это приведет к тому, что отладчик будет "прыгать" по обращениям к подправилам и на них можно будет ставить точки останова.
Это только начало. Для дебаггера необходимы еще
— стэки вызовов
— variables view (с возможностью просмотра и модификации значений переменных, причем значения должны показываться в синтаксисе DSL)
Плюс желательно watch view где юзер может ввести свою конструкцию, которая будет вычислияться в текущем стэк фрейме. Помимо этого нужны доп view для всякой DSL-specific информации.
Я обратил внимание на этот аспект DSL-ей, т.к. мы связаны с большим числом солидных компаний (телеком, военные, авиа) которые в том или ином виде на практике используют (или пытаются, бедняги) свои специализированные языки, генерацию кода, формальные языки спецификаций, DSL-и и т.п. Собственно парсинг/semantic analysis как проблема никогда не стоит. Превейшей задачей является интеграция с унаследованным кодом (т.е. с ЯОН), сторонними библиотеками и т.п. Далее идет проблема дебага генеренного кода а так же интеграция генерации кода по DSL в общуюю систему билда. Плюс поддержка со стороны CM-систем (если над проектом работают много людей, нам надо уметь мержить код и textual merge не всегда хорош)
Я правильно понял вашу идею?
1)"классический" вид абстрактных слоёв.
2)ваша идея.
model — прослойка над выполняющей машиной, например ООП.
Спасибо.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, Ikemefula, Вы писали:
I>Ничего он не выдаст, поскольку проблема в асп и иис, а исключений в том случае про который я говорю, нет и не будет. Потому ДСЛ только затруднит отладку.
Да без разница где проблема. Обрабатывай ошибки показывай клиенту.
I>Вот для такого кода и интересен ДСЛ. То есть описание бизнес-логики в виде ДСЛ.
Еще раз. Ты сначала попробуй пойми что этот код делает. Все кто его смотрел, кроме АВК, так и не смог точно понять что он делает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Почитал дисскуссию по DSL-ям ужаснулся. Заблуждения и не понимание идут со всех сторон (и со стороны сторонников DSL-ей тоже). VD> [...]
У меня тоже хватило духу почитать эту тему. Откровенно говоря, убедился, что "тема не раскрыта". Я так и не понял, в чём глобально ошибаются разработчики языка Go, создавая новый язык программирования общего назначения, причём с расчётом на около системную разработку (именно с этого и начался весь сыр-бор). В той теме правильно заметили, что там сплошной конфликт опыта и эмоций, мало конструктива, ну и традиционное для РСДН кидание песком друг в друга с целью решения вопросов по поводу своего ЧСВ. Более того, как-то сомнительно то, что Вольфхаунд, как человек далеко не глупый, с квалификацией, не вызывающей сомнений, имеет на самом деле такое категоричное мнение, что ЯОН не имеют смысла. Очевидна несколько иная цель в этом форуме — это подпитка себя какой-то энергией, а не решение этого философского вопроса. И то, что его хватает чуть ли не на каждый ответ в топиках той темы, это подтверждает (лично я завидую такой энергетике). А также заметно то, что Вольфхаунд лишний раз старается обратить внимание на свою проделанную работу, которая, бесспорно, вызывает уважение и чувство признательности, особенно со стороны тех, кто использует Немерле. Но в той теме правильно указали, что со 100 людей, кто открыл ссылку, 99 тут же закрывают страницу, увидев там непонятные для себя крокозяблы.
И в целом, задуманная тема форума не имеет запланированного эффекта, на мой взгляд.
Я предлагаю тебе, Влад, возможно совместно с Вольфхаунд, как-то "на пальцах" раскрыть свои позиции по поводу DSL-строения, относительно своего проекта N2 (я так понимаю, что теперь лучше писать именно N2, а не Н2). Правда непонятно, как это сделать, если у вас двоих, как ярких представителей лагеря N, нет однозначного мнения по поводу этих всяких DSL. Когда есть разброс и шатание внутри проекта, то со стороны это выглядит даже не как некий исследовательский проект (в проекте N есть немало неоднозначностей в ключевых целях, это подтверждают ряд профильных тем в форуме Немерле).
А так, например, в той теме ругали SQL все, кому не лень, значит можно взять его как пример DSL, ибо эта сфера всем более-менее знакома всем. И на конкретных, крайне упрощенных, псевдо-примерах показать всю сущность DSL-строения.
Прежде всего, нужно обратить внимание, что нельзя рассматривать какой-то сферический в вакууме DSL, без конкретных целей, что пытались делать многие в той теме, ругая тот же SQL, пытаясь его натянуть как абстрактную сущность чуть ли не для всех задач, для всех "бизнес-систем" и т.п. Например, можно поставить условную задачу для вымышленного SQL-сервера реляционной СУБД:
— скрыть работу внутренних механизмов для манипулирования данными внутри БД, которые обеспечивают сохранность, согласованность в рамках одновременной работы многих пользователей и пр. Одним словом, предоставить пользователям СУБД возможность низкоуровневого доступа к данным (какой-то некий ISAM) для реализации высокоэффективных своих алгоритмов крайне затруднительно или невозможно. Т.е. необходимо дать понять, что здесь востребована какая-то декларативность, невозможно явное детальное алгоритмическое указание действий. Короче говоря, декларативный DSL здесь уместен, даже необходим — т.е. нужно показать, что DSL-строение происходит не "от фонаря", нужно какое-то обоснование в его потребности;
— нужно конкретно сказать, что проектируемый язык должен быть простым, даже для кухарок — это также необходимая конкретная цель для DSL;
— нужен жёсткий контроль типов, необходимо контролировать набор допустимых операций в нужных местах, причём на этапе компиляции SQL-запросов (в большинстве случаев), перед тем, как что-то сделать;
— необходим жёсткий контроль за целостностью и правильностью объектов в БД, например, нельзя удалить столбец в таблице, если он где-то используется, в каких-то View или хранимых процедурах, или необходимо зафиксировать тот факт, что после удаления столбца все зависимые объекты нельзя больше использовать;
— и пр. В принципе, и этого хватит.
Т.е. нужно указать, что DSL должен позволять неявно для пользователя решать широкий круг технический задач, о которых он (пользователь) возможно и не догадывается, всю заботу на себя берёт система СУБД и вынуждена максимально контролировать пользователей-программистов.
Далее на конкретных примерчиках нужно показать, что вкладывается в понятие модели языка, его семантики и пр. Наконец конкретно показать, что подразумевается под DSL, внешний DSL, внутренний DSL, fluent DSL, DSF (domain specific framework) и т.д., а также, что есть какая-то "степень DSL-ности" в языке, или что здесь лишнее и какой есть бред в этих терминах (хотя в личной практике непонимание того, DSL это или кастрированный ЯОН, как-то не мешает для практичного решения задач). Например, можно конкретно показать, что DSL-лем являются выражения для создания/модификации объектов СУБД (DDL, т.е. "create table", "alter index" и т.д.) и выражения для выборки/модификации данных (DML: select ..., insert ...). А вот процедурные расширения вида PL/SQL, TSQL — языки общего назначения, хоть и ограниченные, специализированные, и пользуются этим DSL-SQL. Если ввести какие-нибудь бинарные вставки в SQL-язык вида <<...>> (где внутри, скажем, будет регулярное выражение), и ввести ряд операций над ними — это будет примером встроенного DSL. Если для процедурного расширения добавить функции/процедуры для работы c HTML (или ввести всякие операторы и т.д.), то HTML будет внешним DSL (например, можем реализовать встроенный веб-сервер). Также в рамках процедурного расширения можно показать какой-то способ для создания fluent DSL, если есть какие-то гибкие способы для задания типов, намёки на ООП и т.п.
Можно попробовать усовершенствовать типовой SQL, добавить якобы очень востребованный функционал для декомпозиции запросов, как-то так:
define MyWhere as AnyCol > 1000 and SomeCol is not null;
-- или с параметрами:
define Where2(AnyCol, Val1, Val2) as AnyCol between Val1 and Val2;
define MySelect (AnyTable) as
select Col1, Col2, ... from AnyTable a
where a.ID > 1000 and MyWhere and Where2(a.DateOper, '10.01.2012', '24.08.2012')
-- и использовать как-то так:select * from MySelect(OperTable)
Здесь есть ключевые моменты:
— только в последнем выражении в этом примере система сможет проконтролировать типы, зависимость объектов и допустимость операций и т.д. Т.е. будет ли такой некий generic-SQL соответствовать установленным требованиям и техническим возможностям в СУБД, когда каждый шаг в системе должен быть под прицелом?
— сможет ли с generic-SQL работать каждая кухарка?
— является ли такой generic-SQL каким-то DSL, или это уже специализированный ЯОН, хоть и очень ограниченный и предметно-ориентированный? Ведь расширяется поле его (т.е. SQL) декларативности, повышается уровень абстрактности, т.е. уже есть какая-то возможность для создания domain specific framework, или для уже своего DSL в DSL-е. Т.е. мы изобрели некий аналог функционального языка, который как бы по своей природе является универсальным.
В общем, лучше, когда можно философствовать на конкретных "пальцах".
Все эти изложения необходимо разбавить с конкретными маленькими примерчиками возможной реализации такой СУБД на Немерле. Речь не идёт о подробном описании (это невозможно и только всех отпугнёт подальше). Достаточно условно показать (не полностью) по каким принципам можно реализовать разбор хотя бы одного простейшего оператора вида:
select Col1, Col2 from MyTable where Col3 > 1000 and Col4 like "..."
Нужно в двух словах сказать о том, что используется своя грамматика, как-то похожая на PEG, с парочкой отличительных свойств. Вот таким-то образом задаются декларации, при этом обратить внимание на то, что используется принципы раздельных описаний с возможностью переопределения (т.е. синтаксические модули, с похожими принципами из ООП). Т.е. сказать, что мы можем, например, определить отдельно правила для разбора чисел, строк и т.д., и подключать эти правила для поддержки синтаксисов разных языков. Указать пару слов о принципах по поводу типизации. Намекнуть, как можно реализовать динамическую типизацию, или сказать, что динамическая типизация — это ошибка природы, её нужно однозначно вырубать топором, и начинать нужно с DSL, пока не поздно.
Необходимо показать на маленьком псевдо-коде, как, например, можно внутри своего приложения взять строку с SQL-кодом, что-то вызвать для разбора и как-то воспользоваться его результатом, например, что-то дёрнуть, чтобы сгенерировать какой-то байт-код.
Как-то так. Т.е. нужно показать, как потенциальные разработчики некоего cервера СУБД смогут воспользоваться проектом N2, даже те, кто создаёт платформу на С/С++, частенько не могут задействовать универсальные генераторы парсеров, кому нужна динамическая компиляция во время работы приложения, компактное AST или, вообще, его отсутствие, скорость и эффективность и т.д.
При этом нужно намекнуть, какие планируются вкусняшки в плане IDE. Что-то уже рассматривалось в темах вокруг N2, например, идея об окошках, когда можно править правила для разбора, в другом окне рядом вводить код для разбора, а в ещё в одном окне сразу видеть результат этого разбора. Или какие будут возможности для дебага DSL, ну, например:
model MyModel {
anyField someType "Описание этого поля",
someField anyObj.prop + 125 "А тут вычисления и вывод типа",
...
}
view MyView(MyModel) {
<p>Это форма для ввода</p>
<input MyModel.anyfield />
...
}
Здесь было бы неплохо, если бы отладчик заходил во внутрь каждого декларативного описания, показывал последовательно каждое вычисление внутри, вместо просто того, чтобы проглотить, например, всю декларацию "model ..." как один шаг отладки. Это помогает также лучше понять, как работает конкретный DSL (проверено на личной практике).
Когда будет представлена хоть какая-нибудь конкретика, то появится пища для конструктивных обсуждений. Многие молча смогут задуматься над тем, а не воспользоваться ли DSL (даже для решения какой-то одноразовой задачи, если смогут ощутить, что в случае чего выкинуть этот DSL на помойку не жалко), вместо того, чтобы поливать другу друга брызгами от воплей. И может быть станет понятно, что разработчики языка Go мучаются напрасно, как и их коллеги из нового языка Rust, также можно будет посочувствовать ребятам из jetbrains, которые страдают над своим новым Kotlin, станет понятно, насколько порочны мысли про натягивание Scala, Clojure на платформу Net и т.д. и т.п.
При этом такое простое изложение материала окажется более продуктивным и ненавязчивым, чем прямой крик: "приходите к нам, в проект N2, всем будет хорошо". А также результаты этих трудов (которые будут не больше, чем сотни бессмысленных ответов в топиках мега-ср..ча) не выбросятся на помойку — это неплохой скелет для статейки про N2, которую можно разместить отдельно, включая и вики в проекте.
Как-то так. Прошу сильно не судить.
P.S. Прав был товарищ Толстой: кому нечего сказать — говорит много. Это не адресовано никому конкретно. Это призыв к тому, чтобы не разводить подобной мега-бойни, это отталкивает людей от ресурса РСДН как потенциального источника реальных знаний.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, VladD2, Вы писали:
T>А вот такой вопрос: не мог бы ты предложить хороший вариант DSL'я для работы с файлами?
Любой shell на Linux/Unix — это DSL для работы с файлами, причем проверенный временем.
Здравствуйте, VladD2, Вы писали:
VD>В прочем, не странно для автора не расширяемого языка прошлого поколения. Если сейчас Вирта послушать, то он тоже еще тот ретроград стал.
Почему прошлого? Это вполня нормальный язык, некий pof для ООП языков, некоторые идеи, например, программирование по контракту пошли от него.
кстати вот. Вполне себе развивается.
Что для Вас расширяемость языка? C#, сдается мне, тоже не очень расширяем, если вы не из команды разработчиков компилятора.
Здравствуйте, Sharov, Вы писали:
S>Почему прошлого?
А что в нем современного то?
S>Это вполня нормальный язык, некий pof для ООП языков, некоторые идеи, например, программирование по контракту пошли от него.
Дык в нем дизайн бай контрак и был единственной уникальной фичей. Но этого вообще-то мало для нового языка.
Это дело уже даже из шарпа можно использовать. А в расширяемые языки оно просто вставляется на раз два три.
S>кстати вот. Вполне себе развивается.
Ну, ни хай себе развивается. Только на мой взгляд куда-то не туда. От того и идеи у автора странные.
S>Что для Вас расширяемость языка?
Для меня — это возможность не ждать пока автор языка соизволит проявить милость.
S>C#, сдается мне, тоже не очень расширяем, если вы не из команды разработчиков компилятора.
Ну, да. И это отнюдь не плюс.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, PSV100, Вы писали:
PSV>А так, например, в той теме ругали SQL все, кому не лень, значит можно взять его как пример DSL, ибо эта сфера всем более-менее знакома всем. И на конкретных, крайне упрощенных, псевдо-примерах показать всю сущность DSL-строения.
Для этой цели уже есть готовое DSL решение, LINQ называется.
PSV>Можно попробовать усовершенствовать типовой SQL, добавить якобы очень востребованный функционал для декомпозиции запросов, как-то так: PSV>
PSV>define MyWhere as AnyCol > 1000 and SomeCol is not null;
PSV>-- или с параметрами:
PSV>define Where2(AnyCol, Val1, Val2) as AnyCol between Val1 and Val2;
PSV>define MySelect (AnyTable) as
PSV> select Col1, Col2, ... from AnyTable a
PSV> where a.ID > 1000 and MyWhere and Where2(a.DateOper, '10.01.2012', '24.08.2012')
PSV>-- и использовать как-то так:
PSV>select * from MySelect(OperTable)
PSV>
Тоже пробовать не нужно. В том же MSSQL есть UDF. Не очень удобно технологически, но в разрезе языка это не имеет значения.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, PSV100, Вы писали:
PSV>>А так, например, в той теме ругали SQL все, кому не лень, значит можно взять его как пример DSL, ибо эта сфера всем более-менее знакома всем. И на конкретных, крайне упрощенных, псевдо-примерах показать всю сущность DSL-строения.
AVK>Для этой цели уже есть готовое DSL решение, LINQ называется.
PSV>>Можно попробовать усовершенствовать типовой SQL, добавить якобы очень востребованный функционал для декомпозиции запросов, как-то так: PSV>>
PSV>>define MyWhere as AnyCol > 1000 and SomeCol is not null;
PSV>>-- или с параметрами:
PSV>>define Where2(AnyCol, Val1, Val2) as AnyCol between Val1 and Val2;
PSV>>define MySelect (AnyTable) as
PSV>> select Col1, Col2, ... from AnyTable a
PSV>> where a.ID > 1000 and MyWhere and Where2(a.DateOper, '10.01.2012', '24.08.2012')
PSV>>-- и использовать как-то так:
PSV>>select * from MySelect(OperTable)
PSV>>
AVK>Тоже пробовать не нужно. В том же MSSQL есть UDF. Не очень удобно технологически, но в разрезе языка это не имеет значения.
А вот пример на Хаскель-коде, как непосредственного предка этого LINQ:
[ (the dept, sum salary)
| (name, dept, salary) <- employees
, group by dept
, order by Down (sum salary)
, order using take 5 ]
что соответствует такому SQL:
SELECT dept, SUM(salary)
FROM employees
GROUP BY dept
ORDER BY SUM(salary) DESCENDING
LIMIT 5
И таких DSL куча для разных языков. Вот только такой LINQ в SQL не впихнёшь. Но речь идёт абсолютно не об этом, не о каких-то конкретных SQL-серверах. И лучше сразу оставить какие-то споры по поводу LINQ, SQL и пр. в соответствующей теме этого форума, так такого всякого уже выше крыши.
Здравствуйте, Ikemefula, Вы писали:
I>Ты думаешь, если апи у микрософта кривой, то обложив его картинками, он станет лучше ?
Всем дотнетчикам приходится работать с "кривым API от Майкрософта", с этим ничего не поделать (остальным с "кривым API от SomeCompany"). Яж тебе предлагал показать что-то получше. Все что я видел из не Microsoft, это рельсы, так там язык заточенный под eDSL и описание роутинга выглядит примерно так как я показал.
I>Вот тебе задачка — твой ДСЛ очень классно работает, но вот засада, на одном из серверов в продакше отваливается и урлы не мапятся. I>Без ДСЛ нужно воспроизвести ситуацию и тупо продебажить. Что ты будешь делать с ДСЛ ?
Воспроизведу ситуацию и продебажу
I>Я понимаю, у вас немерлистов хроническая болезнь — при объяснении спрыгивать на свои частные задачки, но это ваши проблемы.
Я так понимаю у тебя, без перехода на личности, дискуссию вести не получается. Я пытаюсь показать, что есть задачи, где DSL удобнее библиотеки с API ...
I>см выше. Правильный пример вот такой — берем бизнес-логику, ну что бы далеко не ходить, из примера AVK. Предложи ДСЛ.
... А ты — что есть задачи, для которых польза DSL не так очевидна. Можешь не стараться, никто не ставит под сомнение этот тезис.
Конкретно по задаче от AVK. Лично я бы не стал сразу придумывать какой-то очень хитрый язык. Совершение бизнес операций путем вызова бизнес-методов разумное решение. Переписав на немерле мы и так получим более читаемый код. Некоторые операции можно было бы подсахарить. Типа
// не должно быть более поздних операцийif (inv.GetInventoryOperations(relatedOperation.AccountingKind, null, null, null, null, null)
.Any(op => op.Order > relatedOperation.Order))
throw new BusinessException("После внутреннего перемещения не должно быть операций.");
может превратиться во что-то типа:
Should not any accounting kind operation of inv with operation.Order > relatedOperation.Order;
А может и не превратиться. По куску кода такие выводы не делаются
Здравствуйте, VladD2, Вы писали: VD>Мелкие модели лежащие под ДСЛ-ем и составляют (в купе с моделями для которых нет ДСЛ-ей) модель приложения. VD>А ЯОН склеивает их вместе создавая приложение.
Как-то так?
Будет возможно реализовать многоуровневые DSL? Что-то вроде такого:
------------------------- VD>...модель приложения.
Под моделью я подразумеваю "модель среды"(не IDE) она же семантика(возможно), а не приложения, то есть всё то что можно использовать для создания программы, посредством языка. Например в Java это объекты, классы, методы etc. в ассемблере это регистры, память, команды, процедур etc.
Когда вы пишете программу вы строите её модель из элементов модели среды:
Как-то так.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, VladD2, Вы писали:
VD>Почитал дисскуссию по DSL-ям ужаснулся. Заблуждения и не понимание идут со всех сторон (и со стороны сторонников DSL-ей тоже). VD>Проблема начинается с невнятности терминологии.
ИМХО пытатря конкретизировать понятие "DSL", это тоже что пытаться конкретизировать например понятие "маленький" или "яркий".
Я бы сказал: "предметными языками программирования" принято называть ЯП разработанные с прицелом на программирование в рамках некоторой предметной области, а ЯОН называют соответственно ЯП разрабатываемые без определённой предметной нацеленности:
-Что на нём можно будет писать?
-Нуу.. разное..
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Как-то так? AC>
Что-то вроде. Только DSLModel скорее нужно называть SymantecModel. И GPLModel тоже. Просто DSL не обазателен. С мелкими моделями можно работать и без них.
Кроме того все эти мелкие модели можно объвести одним большим квадратом и написать на нем ApplicationModel.
AC>Будет возможно реализовать многоуровневые DSL? Что-то вроде такого: AC>
Да, ДСЛ-и могут использовать другие ДСЛ-и для своей реализации. Только это уже детали реализации. ДСЛ и лежащая под ним модель — это абстракция. Если они есть, то детали того как они реализованы уже не важны для общего восприятия приложения.
VD>>...модель приложения. AC>Под моделью я подразумеваю "модель среды"(не IDE)
Приложение он ведь решает некоторую проблему пользователя. Скажем текстовый редактор позволяет создать текстовый документ, а бухгалтерия получить данные по финансам фирмы. Грубо говоря у каждого приложения есть своя задача, а у задачи есть своя большая модель. Модель приложения — это как бы модель предметной области. По сути это составная вещь, и описать ее можно только в виде абстрактных диаграмм. Но все же она есть и не надо забывать об этом.
AC>она же семантика(возможно), а не приложения, то есть всё то что можно использовать для создания программы, посредством языка. Например в Java это объекты, классы, методы etc. в ассемблере это регистры, память, команды, процедур etc.
Классы, другие структуры данных, процедуры, и т.п. — это средства универсального языка (ЯОН). Они используются для реализации семантических моделей. Модель же приложения это как бы совокупность семантических моделей отдельных задач. Скажем в бухгалтерии это могут быть модели отчетов, модель плана счетов, и т.п.
AC>Когда вы пишете программу вы строите её модель из элементов модели среды: AC> AC>Как-то так.
Вот тут уже не совсем так. На самом деле мы используем ЯОН и ДСЛ-и для описания и работы с моделями предметной области. Мы моделируем эту область разными способами. ДСЛ-и это возможность работать с этими моделями в терминах этой предметной области. Только и всего. Если не применять ДСЛ-и то мы будем вынуждены возиться с классами и процедурами которые в свою очередь реализуют модель.
Тут можно провести следующую аналогию. Представь себе, что ты пишешь простую программу которая читаешь данные из файла, производит не сложные их изменения и записывает их в другой файл. Не сложная задача, правда? А теперь представь, что вместо того чтобы программировать, скажем, на С ты вынужден программировать на AST. То есть вместо:
