Подключаемая грамматика – наподобие подключаемой библиотеки – выглядит очень привлекательной альтернативой полностью определенному языку. Позволяет самим реализовать фичи, которые нужны вам сейчас. Позволяет отказаться от ненужного наследства.

Наличие платформы метапрограммирования резко снижает расходы на создание собственного языка или диалекта существующего

Эти два фактора, как мне кажется, являются двужущей силой для изобретения новых языков программирования и смерти существующих.

Тут ключевое слово не "DSL", а "сложный".

Когда мы создаем систему абстракций (классов, интерфейсов, функций и т.п.), то мы тоже создаем свой язык, и если эта система будет сложной, то эффект кирпича тут будет такой же, как и у DSL.

var file = File.Open(...);
try
{
}
finally
{
    if (file != null)
        file.Dispose();
}

using (file = File.Open(...))
{
}

FR>>Ну в них (кроме лиспа) как и в Smalltalk или в D легкий вариант

VD>Легкий? Этого легкого варианта хватило на Рельсы и еще осталось! Он не легкий, он тормозной. А это не одно и тоже .

define function absolute-value(x :: <integer>)
 => (result :: <integer>)
  if (x >= 0)
    x;
  else
    -x;
  end;
end;

FR>>По моему скорее придумают что-то жесткое но более выразительное чем современные языки

using Nemerle.Collections;
using Nemerle.Utility;
using Nemerle.Text;
using Nemerle.WPF;

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Windows.Controls;

using System.Windows;
using System.Console;

public class MyStateControl : Button
{
  public this() { base() }

  [DependencyProperty(Metadata = FrameworkPropertyMetadata("a", (_, _) => { }, (_, b) => b))]
  public DependencyProperty1 : string { get { } set { } }

  [DependencyProperty(IsReadOnly)]
  internal DependencyProperty2 : string { get { } set { } }

  [DependencyProperty(IsReadOnly, ValidateCallback = value => value > 0, Metadata = PropertyMetadata((_, _) => { }))]
  public static GetDependencyProperty3(_ : DependencyObject) : int;

  [DependencyProperty]
  public static GetDependencyProperty4(item : DependencyObject) : int;
}

module Program
{
  [STAThread]
  Main() : void
  {
    try
    {
      def control = MyStateControl();
      control.DependencyProperty1 = control.DependencyProperty1 + control.DependencyProperty2;
      def x = MyStateControl.GetDependencyProperty3(control);
      def y = MyStateControl.GetDependencyProperty4(control);
      MyStateControl.SetDependencyProperty4(control, x + y);
    }
    catch
    {
      | e => WriteLine(e.ToString());
    }
  }
}

Можно привести такой пример: существуют довольно интересные языки программирования Haxe и Boo. Они во многом похожи, например, строгой статической типизацией и выводом типов. Первый язык реализован преимущественно на OCaml, второй — на C#.

Реализация системы типов в Boo, написанном на C#, занимает более семнадцати тысяч строк кода (более половины мегабайта кода на высокоуровневом языке), размещающихся в ста двадцати двух файлах. При этом представлявший наибольший интерес алгоритм вывода типов надежно декомпозирован на слои и «шаблоны проектирования» и код, который его реализует является вполне идиоматичным для этого класса языков. Задача идентифицировать основной код алгоритма и понять его не выглядела решаемой за разумное время и была оставлена.

Ни одной понятной реализации системы типов и алгоритма выведения на императивных языках найдено не было (были рассмотрены варианты на C#, С++ и даже Perl).

Реализация системы типов в языке Haxe, занимает 4088 строк (127624 байт кода) на OCaml и размещается в трех файлах, при этом интересующий алгоритм идентифицируется сразу же и представляет собой, в основном, свертку списков с применением сопоставления с образцом. Прочитать и понять его было достаточно легко, несмотря на то, что на тот момент опыт разработки и чтения кода, написанного на императивных языках, сильно превосходил аналогичный опыт для функциональных.

Даже со всеми возможными оговорками разница в функциональности систем типов Boo и Haxe гораздо меньше, чем разница в количестве кода, эту функциональность реализующего: 100072 строки (2955595 байт) кода текущей реализации Boo убивали всякую надежду, что подобный проект может вообще быть реализован самостоятельно.

Для сравнения, текущие значения для Бипа: 2592 строки (109780 байт) кода, а время, затраченное на реализацию вместе с рантаймом, не превышает трех человеко-месяцев. Это маленький проект, и сделать его маленьким помог именно выбор OCaml в качестве языка разработки.

WH>var file = File.Open(...);
WH>try
WH>{
WH>}
WH>finally
WH>{
WH>    if (file != null)
WH>        file.Dispose();
WH>}
WH>

WH>using (file = File.Open(...))
WH>{
WH>}
WH>

          locker.EnterWriteLock();
          try
          {
            foreach(kv in range)
              hashtable.Add(kv.Key, kv.Value);
          }
          finally
          {
            locker.ExitWriteLock();
          }

          surroundwith (write_lock)
            foreach(kv in range)
              hashtable.Add(kv.Key, kv.Value);

>>но тем сложнее и дольше его поддерживать другим людям.
Это заблуждение обычно муссируют те, кто "знаком" с проблемой теоретически. На практике же как раз поддерживать ДСЛ-и куда проще. Обычно ДСЛ-и весьма просты и очень легко осваиваются (намного проще нежели код решающий ту же задачу).

> Соответственно, это не так популярно потому как компании хотят защититься от эффекта падающего кирпича.
Можно описание этого эффекта?

> Если архитектор DSL покинет компанию или даже заболеет — будут большие проблемы. ОЧЕНЬ большие проблемы.
Чушь полнейшая. Как минимум есть множество примеров ДСЛ-ей широко используемых на практике (BNF, ASP/JSP, Regex). Никаких отличий у доморощенных ДСЛ-ей нет и быть не может.

Неужели перспектива сократить код в 2-3 раза
не сподвигнет вас на изучение небольшого расширения синтаксиса?

Если синтаксис действительно настолько крут, что настолько уменьшает количество кода, то затраты на обучение ему (совсем не такие большие как кажутся) окупаются скоростью разработки и качеством результата.

>>А уж поменять что-нибудь — большой проблемой.
А от это уже зависит от качества реализации "собственного синтаксиса".

Разве никто не здесь не допускает возможности того, что сложность реализации "синтаксиса" эквивалентна написанию библиотеки, а удобство использования в определенных случаях может быть значительно выше?

Не согласен. Взять тот же Qt — это своего рода язык, который надо отдельно изучать. Я знаю С++, но покажи мне программу на Qt — с ходу не разберусь. А почему? Qt не знаю.