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

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

Г>>Тут, чтобы о чём-нибудь разговаривать, нужно бы согласовать словари.

_>Хорошо, сейчас поясню всё на простейшем примере, основываясь на описанной мною в первом сообщение классификации.

[...]

_>Так вот возвращаясь к динамике/статике. Моя основная мысль была в том, что на языке со статическим метапрограммированнием возможна реализация DSL как типа 1.Б (имеет смысл применять только если исполняемый "скрипт" запрашивается снаружи, а не зашит в приложение), так и типа 2.Б. А в языках с динамическим метапрограммированием в принципе возможен только тип 1.Б.

Мне кажется, что помимо (естественного для статики, но не базового для разработки вообще) деления на «проверяемое в компайлтайме» и «проверяемое в рантайме» нужно говорить о делении на проверяемое во время разработки и проверяемое в продакшене.

И польза от идеи DSL в принципе — в том, что у нас получается лаконичный код, отражающий предметную область и надёжно проверяемый во время разработки (несмотря на то, что по классификации с точки зрения статики, всё это попадает в одну и ту же «самую неуважаемую» категорию). Пример (часть примера выше):

class User < ActiveRecord::Base
  has_many :posts # <- DSL!
end

Чем интересна отмеченная строка?
* она сгенерирует некоторое количество кода (методы типа User.add_post, User.remove_post, User.posts.count и т.д.), который скорее всего корректен и оптимален; без этого пришлось бы реализовывать их все вручную и тестировать каждый в отдельности
* она — часть основного языка, и если ты напишешь has many :posts или has_much :posts или has_many posts — тебя поправит конечно не компилятор, но интерпретатор на этапе разработки
* она даёт раннее обнаружение ошибок: например, если таблицы posts не существует в БД или в ней нет ключа для ассоциации — код упадёт сразу при запуске с понятной и читаемой ошибкой (а не в одном из методов в рантайме, в котором ты опечатался в названии таблицы, хотя во всех остальных методах всё верно)

И всё это исключительно для демонстрации мысли, которую я написал как примечание к исходному посту (в целом верному): что плавающая грань между «этапом разработки» и «этапом исполнения» в динамических языках способствует более естественному проникновению идеи DSL в эту среду.