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

DM>>Его сделать сложнее
WH>Да я бы не сказал.
DM>>(и дело отнюдь не в парсинге),
WH>Еще в типизации и кодогенерации.

И даже не в них, тем более, что их вообще может не быть (много ли кодогенерирует make?). Дело именно в обобщении задачи, нацеливании на решение не только имеющейся задачи, но и других из той же области. Иначе DSL будет одноразовым и не оправдает себя. Скажем, есть у меня задача посчитать определенную цепочку матричных операций. В ее конкретном случае часть матриц могут быть особенными (диагональными или симметричными или даже единичными), и эффективное решение может быть довольно простым. Если делать для этого DSL, возникнет желание научить его решать и другие похожие задачи с матрицами (ведь кому нужен DSL для одного частного случая), а в общем случае такой халявы с единичной матрицей не будет, нужно придумывать и реализовывать эффективные решения для намного более сложных задач, чем была изначально.

WH>Так что сложность будет не больше чем при написании библиотеки.

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

DM>> Если же задача штучная, то смысла в таком подходе не видно, тут языки общего назначения и пригодятся. Так что совсем уж их объявлять бессмысленными не стоит.
WH>Только если вычислительная модель задачи совпадает с вычислительной моделью языка. Если же это не происходит, то начинаются проблемы.

Возможно. Просто у многих задач не видно их собственной "вычислительной модели", там любая сгодится (что опыт написания похожих задач на очень разных языках и подтверждает). Скажем, возьмем DVCS. Есть довольно успешные решения на Си, Питоне и Хаскеле — git, mercurial, darcs. Есть ли в той задаче особенная вычислительная модель?