Почитал дисскуссию по 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 (более низкоуровневый и более универсальный), но его все равно надо будет так же во что-то преобразовывавший.