Почитал дисскуссию по DSL-ям ужаснулся. Заблуждения и не понимание идут со всех сторон (и со стороны сторонников DSL-ей тоже).

Проблема начинается с невнятности терминологии. Примеры заблуждений и их обсуждение:
1. DSL — это любой ЯП (язык программирования) использованный в некотором приложении которое специализируется на какой-то предметной области. Примеры: VBA, 1С-язык. По этому же определению получается, что JavaScript-это тоже DSL, если его используют, например, в броузере. Все здорово ребята, но такое широкое трактование делает термин DSL бессмысленным, так как делает термины DSL, и ЯОН (язык программирования общего назначения) близнецами братьями. Стало быть смысл в использовании термина DSL просто исчезает. Или становится зависимым от контекста в кортом применяется язык. Типа LISP в Автокаде — это ДСЛ, а в командной строке — это ЯОН. Чушь!

2. Все на свете языки DSL по сравнению с менее мощными. Очевидно, что такая трактовка опять таки делает термин DSL бессмысленным. Разница с п.1 только в том, что в этот раз DSL-ем подменяется понятие мощность (которое и само плохо детерминировано).

3. DSL есть всегда, так как любая модель предметной области в программе — это DSL. DSL, уважаемые, это в первую очередь ЯЗЫК. Модель ни разу не язык. С моделью можно работать через API. А DSL как раз и предназначен для того, чтобы корявое и не имеющее четких границ API заменить на четкий язык позволяющий заполнить эту модель конкретными данными. Простой пример — реализация КА (конечного автомата) — это модель. А язык позволяющий описывать состояния и переходы КА — это DSL.

4. DSL могут придумывать (выделять) только избранные. Это очень сложно и дано не каждому. В DSL самое важное — это модель. Хороший программист придумывая реализацию задачи разрабатывает модель. Если модель есть, то придумать для нее DSL уже не является сложной задачей. Тут нужно перейти психологический барьер, и дальше будет все довольно просто.

5. Есть мало задач для которых можно придумать DSL. Опять же (см. п.4), если вы можете придумать модель для описания задачи (объектную модель), то можно придумать и DSL.

6. DSL ничего не дает по сравнению с библиотеками. Дает и, порой, очень много. Причем бенефитов получается сразу несколько:
* DSL-и проще изучать и использовать.
* DSL позволяют оградить программистов от ошибок. Синтаксис + проверки в компиляторе/интерпретаторе DSL-я могут исключить целые классы ошибок. Сообщения об ошибках в DSL-ях могут быть значительно более информативными.
* Код на DSL будет всегда компактнее чем если аналогичный код писать вручную. Иногда компактнее на порядки.
* Использование DSL позволяет применять генерацию кода. Это позволяет использовать техники которые вы никогда не стали бы применять при написании кода вручную. Вы можете генерировать тупой но быстрый код. Или можете произвести проверку модели еще во время компиляции, что невозможно при применении библиотек, так как модели в них создаются исключительно в рантайме.

7. DSL увеличивает порог вхождения программиста в проект. Все в точности на оборот. Он снижает этот порог. Проект и без того сложная вещь. Программисту придется изучать модели используемые в проекте, и API работающие с этими моделями. В случае применения DSL-ей нужно изучить только DSL. Так же помогает и уменьшение объемов кода. Потратив время на изучение DSL-я далее человек выигрывает кучу времени пытаясь разобраться с основным кодом проекта.

8. Много DSL-ей превратят проект в зоопарк языков. Их отсутствие превратит проект в груду неподъемного кода. Разумное применение DSL-ей снизит сложность проекта и позволит ему развиваться несмотря на сложность. Кроме того они позволят автоматизировать работу над проектом и генерировать огромный объем кода.

9. DSL-и — это панацея. ЯОН должны умереть. Даже защитники этой позиции признают, что есть не мало задач для которых ЯОН является DSL-ем (что чушь, так как они путают понятие мощности языка и DSL-ность). Это прозрачно намекает на то, что есть ряд задач для которых создавать DSL-и бессмысленно. Кроме того DSL-и частенько надо склеивать вместе. ЯОН может сделать это встраивая конструкции DSL-я в себя. Так же имеет место и обратный процесс. Некоторые DSL-и используют вхождения ЯОН для организации вычислений внутри себя (например, ASP). Я, правда, считаю это ошибкой дизайна, так как это легко превращает такие DSL в Тьюринг-полные языки, что плохо для DSL-ей. Но все же иногда без этого нельзя. Еще один аргумент — DSL-и на чем-то нужно писать. И последний аргумент — по DSL-ям (моделям лежащим под ними) частенько генерируется код. Для генерации проще всего использовать ЯОН. В прочем, можно использовать и другой DSL (более низкоуровневый и более универсальный), но его все равно надо будет так же во что-то преобразовывавший.

Здравствуйте, VladD2, Вы писали:

VD>9. DSL-и — это панацея. ЯОН должны умереть. Даже защитники этой позиции признают, что есть не мало задач для которых ЯОН является DSL-ем (что чушь, так как они путают понятие мощности языка и DSL-ность).
Ох. Это ты себе нафантазировал.

ДСЛность языка можно определить только относительно домена конкретной задачи.
Если язык при решении некоторой задачи позволяет решать ее в терминах ее домена то этот язык является ДСЛем для этой задачи.

ЯОН это язык в качестве целевого домена, которого использована не конкретная задача, а некая абстрактная хрень. ООП, ФП итп.

Бывают случаи, когда домен задачи является поддоменом некоторого ЯОН. В этом случае этот ЯОН становится ДСЛем для этой задачи.

Здравствуйте, VladD2, Вы писали:

VD>Почитал дисскуссию по DSL-ям ужаснулся. Заблуждения и не понимание идут со всех сторон (и со стороны сторонников DSL-ей тоже).

Так что же такое DSL в твоём понимании?

Здравствуйте, WolfHound, Вы писали:

VD>>9. DSL-и — это панацея. ЯОН должны умереть. Даже защитники этой позиции признают, что есть не мало задач для которых ЯОН является DSL-ем (что чушь, так как они путают понятие мощности языка и DSL-ность).
WH>Ох. Это ты себе нафантазировал.

Или ты.

WH>ДСЛность языка можно определить только относительно домена конкретной задачи.

Нет никакой ДСЛности. Есть ДСЛ и не ДСЛ. ДСЛ — это определение языка, а не свойство измеряемое в процентах.

WH>Если язык при решении некоторой задачи позволяет решать ее в терминах ее домена то этот язык является ДСЛем для этой задачи.

Заблуждение 2:

2. Все на свете языки DSL по сравнению с менее мощными. Очевидно, что такая трактовка опять таки делает термин DSL бессмысленным. Разница с п.1 только в том, что в этот раз DSL-ем подменяется понятие мощность (которое и само плохо детерминировано).

ДСЛ должен быть предназначен для решения задач в одной предметной области. Если он позволяет решать задачи из других предметных обалстей, то или он не ДСЛ вовсе (ЯОН), или мы имеем дырявую абстракцию. Что просто баг.

WH>ЯОН это язык в качестве целевого домена, которого использована не конкретная задача, а некая абстрактная хрень. ООП, ФП итп.

От повторения одних и тех же заблуждений эти заблуждения не становятся истиной. ЯОН не имеет предметной области. Он универсален. Использование ЯОН в рамках прикладной задачи не меняет универсальную природу ЯОН.

ЯОН тем и отличается, что может сформировать модель для любой предметной области. А ДСЛ всегда имеет одну предопределенную модель которую и описывает этот ДСЛ. Именно привязка языка к конкретно модели и делает ДСЛ дслем. Погляди теорию моделей. Она как раз эти привязки и рассматривает.

WH>Бывают случаи, когда домен задачи является поддоменом некоторого ЯОН. В этом случае этот ЯОН становится ДСЛем для этой задачи.

Это бессмысленная философия результатом которой является полная бессмысленность термина ДСЛ. Так определенным термином попросту нельзя пользоваться. Так как произнося ДСЛ никто и никогда не сможет понять о чем идет речь.

Здравствуйте, nikov, Вы писали:

VD>>Почитал дисскуссию по DSL-ям ужаснулся. Заблуждения и не понимание идут со всех сторон (и со стороны сторонников DSL-ей тоже).

N>Так что же такое DSL в твоём понимании?

Язык описывающий одну конкретную модель одной конкретной задачи. Например, грамматика описывает модель парсера. Или SQL описывает модель запроса, или регулярное выражение описывает модель конечного автомата распознающего строку.

По сути ДСЛ — это всегда конфигурационный файл для модели которую он описывает.

По сему 1С и VBA не ДСЛ-и, так как позволяют описать произвольные модели.

Здравствуйте, VladD2, Вы писали:

VD>ДСЛ должен быть предназначен для решения задач в одной предметной области. Если он позволяет решать задачи из других предметных обалстей, то или он не ДСЛ вовсе (ЯОН), или мы имеем дырявую абстракцию. Что просто баг.

SQL и XSLT позволяют решать задачи из любой предметной области (так как они тьюринг-полны). Являются ли они DSL-ями?

Здравствуйте, VladD2, Вы писали:

WH>>ДСЛность языка можно определить только относительно домена конкретной задачи.
VD>Нет никакой ДСЛности. Есть ДСЛ и не ДСЛ. ДСЛ — это определение языка, а не свойство измеряемое в процентах.
Ты еще не дал ни одно определения, которое бы не развалилось от одного плевка.

WH>>Если язык при решении некоторой задачи позволяет решать ее в терминах ее домена то этот язык является ДСЛем для этой задачи.
VD>Заблуждение 2:
И причем тут это?

VD>ДСЛ должен быть предназначен для решения задач в одной предметной области. Если он позволяет решать задачи из других предметных обалстей, то или он не ДСЛ вовсе (ЯОН), или мы имеем дырявую абстракцию. Что просто баг.
Или ДСЛ должен быть полным по Тьюрингу и приехали.
С его помощью вдруг стало возможно решать любые задачи.
И ДСЛ превратился в ЯОН.

VD>От повторения одних и тех же заблуждений эти заблуждения не становятся истиной.
В зеркало посмотри.

VD>ЯОН не имеет предметной области. Он универсален. Использование ЯОН в рамках прикладной задачи не меняет универсальную природу ЯОН.
Это как это не имеет? Еще как имеет. От того что ты это отрицаешь C# не перестает быть языком поддерживающим работу с объектами. Это и есть его домен.

VD>ЯОН тем и отличается, что может сформировать модель для любой предметной области.
Не может.
Человек трансформирует модель предметной области в модель ЯОН.
Скажем если ты попытаешься закодировать ПЕГ на C# то тебе придется переводить термины ПЕГ в термины C#.
В ПЕГ нет ни классов, ни методов, ни виртуальных вызовов...
В C# нет ни приоритетного выбора, ни откатов, ни предикатов...

И как бы ты ни крутился, ты не сможешь ввести в C# термины ПЕГ. Что бы ты не делал. Какую бы ты архитектуру не наворачивал. Всё равно все сведется к классам, методам, циклам,...

VD>А ДСЛ всегда имеет одну предопределенную модель которую и описывает этот ДСЛ. Именно привязка языка к конкретно модели и делает ДСЛ дслем. Погляди теорию моделей. Она как раз эти привязки и рассматривает.
Она рассматривает привязку синтаксиса к модели. Ничего про ДСЛ там нет.
Ибо у ЯОН есть своя модель и свой синтаксис.

VD>Это бессмысленная философия результатом которой является полная бессмысленность термина ДСЛ. Так определенным термином попросту нельзя пользоваться. Так как произнося ДСЛ никто и никогда не сможет понять о чем идет речь.
Очень даже можно.
А вот твоим нельзя. Ибо если ДСЛ оказывается полным по Тьюрингу, то он уже и не ДСЛ получается. Даже не смотря на то, что задача решается в его терминах.

Здравствуйте, nikov, Вы писали:

N>SQL и XSLT позволяют решать задачи из любой предметной области (так как они тьюринг-полны).

Начнем с того, что из гипотетической тьюринг-полноты не следует "позволяют решать задачи из любой предметной области". К примеру, отформатируй винт на ANSI SQL или XSLT. Или попробуй на том же ANSI SQL написать мало-мальски серьезное приложение. Если ты и сможешь это сделать (в чем я сильно сомневаюсь), это превратится в ад.

Так что практически эти языки невозможно использовать как ЯОН. Их модель слишком сложно использовать для эмуляции других моделей.

N>Являются ли они DSL-ями?

Являются. Но несомненно тюринг-полнота — это ошибка дизайна. Или, по крайней мере, не самая лучшая черта языка.

Кстати, и без тьюринг-полноты можно успешно использовать вещи не по назначению. Скажем на регулярных выражениях гипотетически можно решать некоторые логические задачи. Но попробуй сделать это на практике.

Здравствуйте, VladD2, Вы писали:

VD>По сему 1С и VBA не ДСЛ-и, так как позволяют описать произвольные модели.

Я в ту тему не решился влезать (сообщений слишком много, еще и ругаетесь там между собой ), поэтому возможно эту мысль уже кто-то высказал... ИМХО, проблема недопонимания тут в том, что многие путают DSL с DSF (domain specific framework). 1С, VBA, javascript — это ЯОП к прикрученными к ним DSF'ами. Т.е. их предметно-ориентированность определяется именно наличием наглухо встроенных библиотек, объектных моделей и тому подобной радости, не имеющей прямого отношения к этим языкам. Вместо любого из них можно воткнуть произвольный ЯОП и "степень предметно-ориентированности" от этого не изменится, т.к. определяется внешними по отношению к языку средствами.

DSL'ем же язык является тогда, когда его дизайн исключает необходимость использования внешних DSF и не требует их разработки на этом языке для решения задач предметной области.

Здравствуйте, WolfHound, Вы писали:

VD>>ЯОН тем и отличается, что может сформировать модель для любой предметной области.
WH>Не может.
WH>Человек трансформирует модель предметной области в модель ЯОН.
WH>Скажем если ты попытаешься закодировать ПЕГ на C# то тебе придется переводить термины ПЕГ в термины C#.

Мне придется описать на шарпе модель ПЕГ-а. Только и всего. Ты зделал это на Немерле. Это же можно сделать и на шарпе. Сложнее, но можно. ЯОН есть ЯОН.

WH>В ПЕГ нет ни классов, ни методов, ни виртуальных вызовов...

В Н тоже нет сущностей ПЕГ-а. Но тебе это не помешало создать вот эту модель.

WH>В C# нет ни приоритетного выбора, ни откатов, ни предикатов...

И не нужно. Зато в нем есть все чтобы воспроизвести любую модель! А модель уже можно заполнить (грамматикой, например, через АПИ) и интерпретировать или компилировать (в те же экспрешон-три, например).

WH>И как бы ты ни крутился, ты не сможешь ввести в C# термины ПЕГ. Что бы ты не делал. Какую бы ты архитектуру не наворачивал. Всё равно все сведется к классам, методам, циклам,...

И не надо вводит. ЯОН может создать модель не вводя в своей лексикон термины модели.

WH>Она рассматривает привязку синтаксиса к модели. Ничего про ДСЛ там нет.

ДСЛ частный случай языка. Теория не может быть завязана на частные случаи.

WH>Ибо у ЯОН есть своя модель и свой синтаксис.

Ну, да. Только для ЯОН — это модель Фон Нэймана. А у этой модели есть одна характерная черта — она позволяет решать любые задачи, в том числе и формировать модели.

Вот в этом и отличие ДСЛ от ЯОН. ЯОН может все так как его модель универсальна. ДСЛ может только то, что позволяет его модель.


VD>>Это бессмысленная философия результатом которой является полная бессмысленность термина ДСЛ. Так определенным термином попросту нельзя пользоваться. Так как произнося ДСЛ никто и никогда не сможет понять о чем идет речь.
WH>Очень даже можно.
WH>А вот твоим нельзя. Ибо если ДСЛ оказывается полным по Тьюрингу, то он уже и не ДСЛ получается. Даже не смотря на то, что задача решается в его терминах.

Я уже отвечал на этот вопрос много раз. Читай что я писал.

Здравствуйте, VladD2, Вы писали:

VD> К примеру, отформатируй винт на ANSI SQL или XSLT.

Это вопрос API, а не языка. Запусти-ка в космос ракету. Язык — любой.

Здравствуйте, VladD2, Вы писали:

VD>Мне придется описать на шарпе модель ПЕГ-а. Только и всего. Ты зделал это на Немерле. Это же можно сделать и на шарпе. Сложнее, но можно. ЯОН есть ЯОН.
Ты можешь ее описать на шарпе. Но не добавить в C#.
Ибо, какие бы ты классы не описывал на C#, ты всё равно будешь использовать классы и методы, а не правила ПЕГ.

VD>В Н тоже нет сущностей ПЕГ-а. Но тебе это не помешало создать вот эту модель.
Так она не в Н. А сама по себе. От того что я описал на Н модель ПЕГ в самом Н она не появилась.

VD>И не нужно. Зато в нем есть все чтобы воспроизвести любую модель! А модель уже можно заполнить (грамматикой, например, через АПИ) и интерпретировать или компилировать (в те же экспрешон-три, например).
Нет. Что бы ты ни делал, ты всё равно будешь на C# работать в терминах C#.

WH>>Она рассматривает привязку синтаксиса к модели. Ничего про ДСЛ там нет.
VD>ДСЛ частный случай языка. Теория не может быть завязана на частные случаи.
Вот и не приплетай теорию просто так.

WH>>Ибо у ЯОН есть своя модель и свой синтаксис.
VD>Ну, да. Только для ЯОН — это модель Фон Нэймана.
Тут ты не прав. Тот же C# не имеет ничего общего с моделью Фон Нэймана. И может с тем же успехом транслироваться в Гарвардскую архитектуру.

VD>А у этой модели есть одна характерная черта — она позволяет решать любые задачи, в том числе и формировать модели.
Она не позволяет решать любые задачи в терминах предметной области.
Она позволяет перевести в нее любой домен.
Руками или компилятором не важно.
Но всегда есть процесс превращение терминов предметной области в термины целевой вычислительной модели.
То, что ты в своей голове научился делать прямой и обратный перевод совершенно не означает, что в C# вдруг появились термины предметной области.

VD>Вот в этом и отличие ДСЛ от ЯОН. ЯОН может все так как его модель универсальна. ДСЛ может только то, что позволяет его модель.
Любой полный по Тьюрингу язык может все.
Это доказано строго математически.

VD>Я уже отвечал на этот вопрос много раз. Читай что я писал.
Ничего ты не ответил.
Твое определение разбивается о вычислительную полноту.
А так как ДСЛи бывают и полными по Тьюрингу то твое определение неприемлемо.
Оно вообще содержит слишком много субъективности.
Мое же определение объективно. И для него даже при желании метрику придумать можно.

Здравствуйте, nikov, Вы писали:

N>Это вопрос API, а не языка. Запусти-ка в космос ракету. Язык — любой.

Дык ДСЛ на то и ДСЛ, чтобы ограничивать и вопросы АПИ. А для ЯОН нормально позволять загружать внешние библиотеки.

Я не говорю, что это единственный критерий. Но наличие в языке средств загрузки внешних объектов как бы кричит о том, что мы имеем дело с ЯОН.

Здравствуйте, VladD2, Вы писали:

VD>3. DSL есть всегда, так как любая модель предметной области в программе — это DSL. DSL, уважаемые, это в первую очередь ЯЗЫК. Модель ни разу не язык.

Любая модель — язык, и при этом модель ни разу не язык
Язык это в основном синтаксим синтаксис, а модель в основном семантика. Вот так всё становится на свои места.

VD>4. DSL могут придумывать (выделять) только избранные. Это очень сложно и дано не каждому. В DSL самое важное — это модель. Хороший программист придумывая реализацию задачи разрабатывает модель. Если модель есть, то придумать для нее DSL уже не является сложной задачей. Тут нужно перейти психологический барьер, и дальше будет все довольно просто.

Для того, что бы выяснить, где же сложность и чем она обсуловлена, нужно четко разделить понятия модель и язык. Судя по противоречию которое ты выдал, ты сам плохо понимаешь, в чем причина барьеров.

VD>7. DSL увеличивает порог вхождения программиста в проект. Все в точности на оборот. Он снижает этот порог. Проект и без того сложная вещь. Программисту придется изучать модели используемые в проекте, и API работающие с этими моделями. В случае применения DSL-ей нужно изучить только DSL. Так же помогает и уменьшение объемов кода. Потратив время на изучение DSL-я далее человек выигрывает кучу времени пытаясь разобраться с основным кодом проекта.

См, выше — у тебя путаница между моделью и дсл. Изучать нужно в первую очередь модель, то есть, семантику. Понять её по ДСЛ часто не только сложно, но и вообще невозможно.

VD>8. Много DSL-ей превратят проект в зоопарк языков. Их отсутствие превратит проект в груду неподъемного кода. Разумное применение DSL-ей снизит сложность проекта и позволит ему развиваться несмотря на сложность. Кроме того они позволят автоматизировать работу над проектом и генерировать огромный объем кода.

Вот бы кто выдал формулу нахождения границы разумности-неразумности.

И мифы про ДСЛ : "Если модель есть, то придумать для нее DSL уже не является сложной задачей."

Придумать язык не сложно. Сложно придумать язык, который будет легко поддерживаться, расширяться, будет легок в изучении. А еще трудно придумать язык в котором на раз будут решаться проблемы с производитеностью. Глядя на известные ДСЛ совершенно не очевидно, что второе и третье это легко.

Здравствуйте, Ikemefula, Вы писали:

VD>>3. DSL есть всегда, так как любая модель предметной области в программе — это DSL. DSL, уважаемые, это в первую очередь ЯЗЫК. Модель ни разу не язык.

I> Любая модель — язык, и при этом модель ни разу не язык

Ну, вот и представитель этого заблуждения появился.

I>Язык это в основном синтаксим синтаксис, а модель в основном семантика. Вот так всё становится на свои места.

Ага. И язык без синтаксиса не бывает. Без семантики тоже не бывает, так что модель должна быть у любого языка. Но наличие модели не создает автоматом язык. Для одной модели можно придумать большое количество синтаксисом.

I>Для того, что бы выяснить, где же сложность и чем она обсуловлена, нужно четко разделить понятия модель и язык. Судя по противоречию которое ты выдал, ты сам плохо понимаешь, в чем причина барьеров.

в зеркало посмотри. Ты отрицаешь очевидное. У тебя возможен язык без синтаксиса.

Короче, как всегда обсуждать с тобой особо не чего. Сори, дальше читать не стал.

VD>Почитал дисскуссию по DSL-ям ужаснулся. Заблуждения и не понимание идут со всех сторон (и со стороны сторонников DSL-ей тоже).

Да нет же, люди гораздо проще к этому относятся:
"А он изобретает DSL-и. Должно быть, квартиру сдаёт."
НЕНАВИСТЬ!!!

Здравствуйте, Ikemefula, Вы писали:

I>См, выше — у тебя путаница между моделью и дсл. Изучать нужно в первую очередь модель, то есть, семантику. Понять её по ДСЛ часто не только сложно, но и вообще невозможно.

DSL это всего лишь способ упростить код. Код проще для понимания будет проще и для поддержки. Вот смотри, есть задача для маппинга RESTful урлов. Если ты сталкивался, то знаешь, что в ASP.NET MVC замапить контроллер ресурсов так достаточно неудобно.

Приходится делать eDSL типа такого:

            map.Resources<StoriesController>(c =>
                                                {
                                                    c.Except("new", "edit", "index");
                                                    c.Member(x => x.Put("ChangePosition"));
                                                    c.Member(x => x.Put("Bind"));
                                                    c.Member(x => x.Put("UnBind"));
                                                    c.Collection(x => x.Get("Feed"));
                                                    c.Collection(x => x.Get("GetIndependent"));
                                                    c.Collection(x => x.Get("SearchIndependent"));
                                                    c.Collection(x => x.Get("Search"));
                                                    c.Resources<StoryBlocksController>();
                                                });

Если бы была возможность сделать нормальный DSL, код превратился бы в:

Resources Stories 
{
   Member 
   {
     Except new, edit, index;
     Put ChangePosition, Bind, Unbind;
     Resources StoryBlocks;
   }
   Collection
   {
     Get Feed, GetIndependent, SearchIndependent, Search;
   }
}

Гораздо приятнее в поддержке, ключевые слова будут подсвечены, обеспечит контроль контроллеров и их методов на этапе компиляции. На этапе выполнения тоже есть плюсы, выполняться будет код создания маршрутов, а не код их конфигурации, а потом уже создания по ней.

И, самое главное по теме, сложность разработки и поддержки этого DSL будет ниже чем сложность разработки eDSL приведенного выше. Все кто писал более менее сложные fluent DSL меня поймут. Сложность использования у нас тоже не всегда в пользу первого, а уж в N2, где можно будет обеспечить свой автокомплит вообще сравнивать не приходится.

Здравствуйте, VladD2, Вы писали:

VD>>>3. DSL есть всегда, так как любая модель предметной области в программе — это DSL. DSL, уважаемые, это в первую очередь ЯЗЫК. Модель ни разу не язык.
I>> Любая модель — язык, и при этом модель ни разу не язык
VD> Ну, вот и представитель этого заблуждения появился.

Я вообще то сказал, что ДСЛ и модель это совершенно разные вещи. раз ты считаешь, что это заблуждение, то с тобой не о чем говорить.

Здравствуйте, VladD2, Вы писали:

VD>Являются. Но несомненно тюринг-полнота — это ошибка дизайна. Или, по крайней мере, не самая лучшая черта языка.

Полнота по тьюрингу не имеет никакого отношения к дсл.

Здравствуйте, VladD2, Вы писали:

кодом проекта.

VD>8. Много DSL-ей превратят проект в зоопарк языков. Их отсутствие превратит проект в груду неподъемного кода. Разумное применение DSL-ей снизит сложность проекта и позволит ему развиваться несмотря на сложность. Кроме того они позволят автоматизировать работу над проектом и генерировать огромный объем кода.

VD>9. DSL-и — это панацея. ЯОН должны умереть. Даже защитники этой позиции признают, что есть не мало задач для которых ЯОН является DSL-ем (что чушь, так как они путают понятие мощности языка и DSL-ность). Это прозрачно намекает на то, что есть ряд задач для которых создавать DSL-и бессмысленно. Кроме того DSL-и частенько надо склеивать вместе. ЯОН может сделать это встраивая конструкции DSL-я в себя. Так же имеет место и обратный процесс. Некоторые DSL-и используют вхождения ЯОН для организации вычислений внутри себя (например, ASP). Я, правда, считаю это ошибкой дизайна, так как это легко превращает такие DSL в Тьюринг-полные языки, что плохо для DSL-ей. Но все же иногда без этого нельзя. Еще один аргумент — DSL-и на чем-то нужно писать. И последний аргумент — по DSL-ям (моделям лежащим под ними) частенько генерируется код. Для генерации проще всего использовать ЯОН. В прочем, можно использовать и другой DSL (более низкоуровневый и более универсальный), но его все равно надо будет так же во что-то преобразовывавший.
Я тут давно предлагаю вариант унивесального языка с единым синтаксисом и на нем можно строить другие языки со своими терминами, но правила синтасиса остается теми же. Но надо кое-что в голове изменить. Потому я не согласен что ЯОН дожен умереть. Предметные языки само собой буду развиваться. Причины очевидны.