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

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

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

DM>Возможно. Просто у многих задач не видно их собственной "вычислительной модели", там любая сгодится (что опыт написания похожих задач на очень разных языках и подтверждает). Скажем, возьмем DVCS. Есть довольно успешные решения на Си, Питоне и Хаскеле — git, mercurial, darcs. Есть ли в той задаче особенная вычислительная модель?
DVCS это интересная тема.
И там на самом деле можно очень легко найти, где можно применить ДСЛ с очень большой отдачей.
Все DVCS это по сути базы данных. Но очень конкретные. Типа как SQL серверы с несколькими фиксированными таблицами.
Но если подумать, то не сложно сделать обобщенную базу данных не уступающую конкретным.
При этом мы сможем в DVCS хранить не только исходники, но и трекер и вики и форум и отчеты continuous integration систем и много чего еще что обычно размазано по куче разных слабо связанных программ. При этом все это будет связано между собой. И можно будет простыми запросами к БД получить информацию обо всех активностях связанных с конкретным коммитом.