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

A>Вы забываете про другую букву в абривиатуре DSL, а именно D. Есть домен -- можно создать ДСЛ. Нет домена -- будет синтаксический сахар, ИХМО.

Логично, согласен.

A>Я со скалой практически не знаком, но, ИХМО, в том что показывал dimgel домена нет.

В ListBuffer, получается, нет. А в scalatest — есть: тестирование.

A>Если мы обратимся к linq, то там домен есть -- наборы данных. Поэтому Linq -- DSL.

+1.

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

LP>В продолжение темы Языки общего назначения не имеют смысла

Автор: WolfHound
Дата: 07.04.12

Вообще говоря — DSL это не обязательно другой язык. DSL во многих случаях представляет собой просто набор либ, упрощающие рутинные операции. jQuery, например — это вполне DSL для своих задач. Или arrowlets — тоже DSL для своих задач (чтоб не писать кучу подписчиков и отписчиков от событий). Когда ты решаешь более высокоуровневую объемную задачу, в которой многие операции повторяются изо дня в день — ты тоже напишешь свой DSL. Например для генерации формочек — ты описываешь какие элементы будут на формочке, как их биндить, сделаешь синтаксис максимально компактным читаемым и поддерживаемым, и будет тебе DSL. Который можно реализовать средствами своего языка программирования, а декларативность будет достигаться использованием мапок. SQL это тоже низкоуровневый DSL. Но когда делаешь более-менее универсальный поиск, SQLем обойтись сложно, хочется писать меньше кода и будет еще один DSL, который будет строить запросы.
А язык общего назначения — это if else for goto и ничего более. Минимальный набор операторов с помощью которых можно реализовать что требуется. Вот только оставаться в рамках только операторов — это большая глупость, и если тебе не платят за количество строк кода, ты так поступать не будешь и будешь городить что то, упрощающее тебе жизнь и позволяющее писать более компактно и понятно. Даже списки — это уже по существу DSL, хоть и вырожденный. Ты компактно описываешь все, что ты хочешь от области памяти, и пишешь код более компактно, а не каждый раз проверяешь выход за границу массива и тому подобное. А всякие JMockit — это вполне полноценный DSL, хоть и сделанный средствами языка и остающийся в рамках языка.

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

LP>1. Возможность подобного радикального сокращения существует только для задач, которые изначально плохо ложатся на выбранный императивный (объектно-ориентированный или функциональный) язык общего назначения. Но и задач, в которых оправдано использование декларативного языка (такого, как Datalog), совсем немного. По правде говоря, в практике обычного программиста их почти нет. Таким образом выгоды от использования декларативных dsl-ей, мягко говоря, преувеличены. Их просто негде применить. Неудивительно, что сторонники DSL "не поняли" код, предложенный AndrewVK в качестве примера для демонстрации мощи DSL-я. А секрет прост — Андрей предложил чисто императивный код, который не перепишешь на том же даталоге.

На Dataloge переписали всю программу, а не какой-то кусок одной из функций, как предложил сделать Андрей.

LP>2. Спрашивается, при чем же здесь собственно сам DSL? Эдак ведь и тот же хаскель можно считать DSL-ем, да и вообще любой язык, отличный от языка реализации.

Ессно любой. Тот же C# уже включает в себя несколько DSL, linq, async/await. Тот же using (для IDisposable) и lock это мини DSL. В яве DSL разрабатываются для ORM и DI контейнеров. DSL давно уже проникли в нашу жизнь, вопрос только в том, что их создание все еще чересчур трудоемкая процедура для повседневного применения. Вольфхаунд утверждает, что не за горами будущее, когда создание DSL будет равно созданию библиотеки. И применяться будет столь же часто.

LP>3. Пикантность ситуации в том, что DSL-и таки повсеместно используются в индустрии. Та же объектно-ориентированная модель предметной области — пример DSL-я (а точнее, его ядра), массово используемого на практике. И в приведенном Андреем коде уже используется DSL, составленный из модели инвентарных карточек и структур языка ОН для манипулирования ею. Модель предметной области может быть легко сгенерирована из UML-подобного представления. Я в последнее время, к примеру, описываю модели исключительно на EMF.

Совершенно верно. Графические дизайнеры это еще не все. За неимением средств расширения синтаксиса, часто, для предметной области сейчас делается некий API в рамках стандартного синтаксиса ЯОН. Этот API настолько близок к понятию DSL, что совершенно непонятно, где проводить границу. Особенно близко к отдельному языку получаются fluent API.

Query luceneQuery = mythQB
    .bool()
      .must( mythQB.keyword().onField("description_stem").matching("urban").createQuery() )
        .not()
      .must( mythQB
        .range()
        .onField("starred")
        .from(3).excludeLimit()
        .to(5)
        .createQuery() )
      .must( mythQB
        .range()
        .onField("creationDate")
        .above(twentiethCentury)
        .createQuery() )
    .createQuery();

K>Я думал-думал, я всё понял!

K>Главная причина непринятия DSL — крайне неудачные примеры введения в метапрограммирование.

Не знаю. У меня главная причина неприятия — то, что любой DSL — это еще один язык, зачастую недокументированный, часто со странной и отличающейся от других языков семантикой, с отсутствием внятного инструментария и т.п.

Потому что даже в том же SQL, который является DSL'ем с собственным стандартом и основан на известной мат. модели, разные реализации имеют собственные детали, инструменты, уровень документированности и проч. Про мелкие DSL'и, которые здесь пытаются активно продивигать (типа «каждой задаче по DSLю») я вообще промолчу.

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

Z>Тот же C# уже включает в себя несколько DSL, linq, async/await. Тот же using (для IDisposable) и lock это мини DSL.

Между этими DSL и тем, что предлагается есть существенная разница — первые прописаны в универсальном стандарте C# и их знание можно ожидать от любого приличного разработчика, заявляющего о владении шарпом. Что же касается языков имени меня, то им придется обучать всех, кроме меня самого.

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

AVK>Между этими DSL и тем, что предлагается есть существенная разница — первые прописаны в универсальном стандарте C# и их знание можно ожидать от любого приличного разработчика, заявляющего о владении шарпом. Что же касается языков имени меня, то им придется обучать всех, кроме меня самого.

DSL в этом плане ничем не отличается от библиотек которые не входят в поставку фреймворка. Без которых редко обходится любое более менее крупное приложение. И уж точно, во всех проектах применяются классы имени меня. Их применению приходится обучать всех кроме меня самого. В чем отличие?

Вот я в упор не вижу разницы в читабельности кода:

var message = json {text: "Hello world!", data: {code: 1}};
// vs
var message = Json.Create(new {text = "Hello world!", data = Json.Create(new {code = 1})});

Точнее я ее вижу в пользу DSL, и убежден, что специально обучать кого-то использованию такого DSL придется не дольше чем применению аналогичной библиотеки.

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

M>Не знаю. У меня главная причина неприятия — то, что любой DSL — это еще один язык, зачастую недокументированный, часто со странной и отличающейся от других языков семантикой, с отсутствием внятного инструментария и т.п.

Обычно документированный. Давай примеры тех DSL с которыми тебе приходилось работать и безDSLную альтернативу, чтобы было с чем сравнивать.

M>Потому что даже в том же SQL, который является DSL'ем с собственным стандартом и основан на известной мат. модели, разные реализации имеют собственные детали, инструменты, уровень документированности и проч. Про мелкие DSL'и, которые здесь пытаются активно продивигать (типа «каждой задаче по DSLю») я вообще промолчу.

Пример SQL показывает, что как только появляется хороший DSL все остальные решения можно хоронить.

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

Z>DSL в этом плане ничем не отличается от библиотек которые не входят в поставку фреймворка.

Отличается. Одно дело разобраться в библиотеке, и совсем другое — разобраться вновом языке, особенно если это не как бы DSL типа флюента и не простенький сахарок типа линковского QC, а полноценные специализированные ЯП типа сиквела или упоминавшегося тут дейталога.

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

Z>Пример SQL показывает, что как только появляется хороший DSL все остальные решения можно хоронить.

Пример SQL показывает, что при наличии в языке средств типа LINQ он нужен примерно как собаке пятая нога.

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

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

Z>>Пример SQL показывает, что как только появляется хороший DSL все остальные решения можно хоронить.

AVK>Пример SQL показывает, что при наличии в языке средств типа LINQ он нужен примерно как собаке пятая нога.

ну так как раз линк и доказывает, что ДСЛ встроенный в "основной" язык — это и есть рулез нереальный.

M>>Не знаю. У меня главная причина неприятия — то, что любой DSL — это еще один язык, зачастую недокументированный, часто со странной и отличающейся от других языков семантикой, с отсутствием внятного инструментария и т.п.

Z>Обычно документированный.

С какого перепугу?

Z>Давай примеры тех DSL с которыми тебе приходилось работать и безDSLную альтернативу, чтобы было с чем сравнивать.

У нас на работе используется 3, по сути DSL'я. Уровень документации во всех трех — аховый. Без-DSLная алтернатива — описывать все то же в Erlang'е.

M>>Потому что даже в том же SQL, который является DSL'ем с собственным стандартом и основан на известной мат. модели, разные реализации имеют собственные детали, инструменты, уровень документированности и проч. Про мелкие DSL'и, которые здесь пытаются активно продивигать (типа «каждой задаче по DSLю») я вообще промолчу.

Z>Пример SQL показывает, что как только появляется хороший DSL все остальные решения можно хоронить.

Осталось понять, каким образом такой хороший DSL может появиться. Это во-первых. Во-вторых — выделенное.

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

J>ну так как раз линк и доказывает, что ДСЛ встроенный в "основной" язык — это и есть рулез нереальный.

Нет, не доказывает. DSL это не весь линк, а конкретно query comprehension. И вот лично я им практически никогда не пользуюсь. Ключевой момент языка, который меняет картину, это прежде всего механизм квазицитирования ака expression tree, и это вполне себе general purpose штука, а никак не DSL.

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

AVK>Отличается. Одно дело разобраться в библиотеке, и совсем другое — разобраться вновом языке, особенно если это не как бы DSL типа флюента и не простенький сахарок типа линковского QC, а полноценные специализированные ЯП типа сиквела или упоминавшегося тут дейталога.

Ну ты все-таки соизмеряй масштабы примеров. Если предметная область оказалось настолько суровой, что потребовалось наколбасить крутой DSL уровня SQL, то и библиотека классов с аналогичным функционалом должна быть некислого размера.

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

AVK>Отличается. Одно дело разобраться в библиотеке, и совсем другое — разобраться вновом языке, особенно если это не как бы DSL типа флюента и не простенький сахарок типа линковского QC, а полноценные специализированные ЯП типа сиквела или упоминавшегося тут дейталога.

Чтобы разобраться в DSL надо разобраться в предметной области. Это придется делать в любом случае. Зато потом на SQL ты будешь легко писать каскадные джойны, а на уровне API дальше быстрого поиска по индексу дело не пойдет, слишком сложный API будет, не осилит народ.

То же самое и Datalog, ты все равно будешь программировать в терминах предикатов, правил и атомов. Только выглядеть это в коде будет китайской грамотой вперемешку с низкоуровневыми вызовами всякой ерунды типа indexLookup.

Думаешь WPF был бы так популярен, если бы вместо разметки пришлось писать на C#? Даже с учетом генерации кода графическим дизайнером. Продвинутые WPFщики дизайнер юзают редко (он больше нужен как костыль для новичков), а пишут прямо на XAML, хотя он далеко не образец удобного DSL.

Все примеры с DSL которые я вижу достаточно документированы и осваиваются быстрее чем аналогичный API, если у тебя есть контрпримеры, давай их.

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

H>Если предметная область оказалось настолько суровой, что потребовалось наколбасить крутой DSL уровня SQL

А если такой DSL не нужен, то и пушка навроде той, что Влад предлагал, тоже не нужна.

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



K>Главная причина непринятия DSL — крайне неудачные примеры введения в метапрограммирование. Сколько я видел кратких введений в МП — везде приводятся крайне неудачные примеры: ставится простенькая задача, пишется функция, решающая эту задачу, затем вместо функции пишется расширение (оператор) языка, решающий ту же задачу. Увы, именно такими примерами напрочь отбивают принятие МП и DSL. Ведь сокращение кода не происходит: была функция, стало новое слово языка; упрощение кода тоже не происходит (по той же причине).

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

K>Просто нужна правильная пропаганда. Нужны правильные примеры. Да, здесь, на РСДН, такие примеры есть (естессно, на Немерле). Здесь приведено множество крайне удачных примеров, когда МП в разы сокращает код, избавляет от копипасты, упрощает понимание кода. Увы, лишь некоторые дотнетчики обращают на них внимание. Все остальные — продолжают оставаться в дремучем неведении, что МП и DSL — не нужны.

Как то так выходит, что самые лучшие примеры по ДСЛ и Немерле от людей, которые мягко говоря не в ладах с местными немерлистами.

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

AVK>Нет, не доказывает. DSL это не весь линк, а конкретно query comprehension. И вот лично я им практически никогда не пользуюсь. Ключевой момент языка, который меняет картину, это прежде всего механизм квазицитирования ака expression tree, и это вполне себе general purpose штука, а никак не DSL.

query comprehension конечно можно не пользоваться, но глупо заменять несколько строчек с джойнами на букет нечитабельных SelectMany. Без синтаксиса linq не взлетел бы, ибо рассматривался бы только как игрушка для простых запросов и удобный билдер условий.

Если хочешь доказать, что query comprehension туфта, перепиши запрос без него:

orderDetails = 
    from o in db.Orders
    where o.OrderID == orderID
    join s in db.Shippers on o.ShipVia equals s.ShipperID
    join od in db.OrderDetails on o.OrderID equals od.OrderID
    join p in db.Products on od.ProductID equals p.ProductID
    join supplier in db.Suppliers on p.SupplierID equals supplier.SupplierID
    let total = od.Quantity * od.UnitPrice
    select new OrderDescription
    {
      Product = p.ProductName,
      Quantity = od.Quantity,
      ShipperName = s.CompanyName,
      Total = total,
      UnitPrice = od.UnitPrice,
      SupplierName = supplier.CompanyName
    };

Я считаю это будет отличный способ доказать, что использование API вместо DSL позволяет писать код понятнее и избавляет от необходимости изучения нового языка.

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

AVK>А если такой DSL не нужен, то и пушка навроде той, что Влад предлагал, тоже не нужна.

Мой акцент был не на сложности DSL-я, а на сложности прямого аналога этого DSL-я на типичном ООП языке.

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

Z>>Обычно документированный.

M>С какого перепугу?

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

M>У нас на работе используется 3, по сути DSL'я. Уровень документации во всех трех — аховый. Без-DSLная алтернатива — описывать все то же в Erlang'е.

А как писать все то же, но в Erlange документировано лучше? Ты примеры давай, я тебе верю конечно на слово, но без примеров дискутировать не очень интересно.

M>Осталось понять, каким образом такой хороший DSL может появиться. Это во-первых. Во-вторых — выделенное.

Так же как и любой другой код для повторного использования. Он появляется потому, что без него еще хуже. А уж будет этот код документирован и продуман не зависит от того, DSL это или нет.

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

H>Мой акцент был не на сложности DSL-я, а на сложности прямого аналога этого DSL-я на типичном ООП языке.

Когда логика не помогает, в ход идут акценты?