Как стать автором
Обновить

Комментарии 12

НЛО прилетело и опубликовало эту надпись здесь
Вы верно заметили. Это обычный Kotlin код. Если быть точнее, это набор стандартных конструкций языка, благодаря которым мы строим проблемно-ориентированный язык, который специфичен для нашего проекта. Чем в вашем понимании «проектно специфичный фреймворк» отличается от DSL?
А где сам язык, который вы построили? Что он может, чем он удобен, в конце концов?

Я вообще не уверен, что хаки с синтаксическим сахаром и набор утилитных функций (которые не похожи на код, но компилируются! вот прикольно!) — это уже DSL.
А где сам язык, который вы построили?

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

Использование элементов языка общего назначения для получения специфичных для решаемой задачи конструкций — это один из вариантов построения DSL. Вы можете убедиться в этом сами по ссылке и в других источниках по запросу «internal domain-specific language»
Возможно, в данном случае мы видим пример EDSL

Согласитесь, удобно описать сложный тест-кейс в виде кода
MyLittleDSL
schedule {
            data {
                startFrom("08:00")

                subjects("Russian",
                        "Literature",
                        "Algebra",
                        "Geometry")

                student {
                    name = "Ivanov"
                    subjectIndexes(0, 2)
                }


Альтернатива — многоэтажные if/case которые не всегда с первого раза прочтешь.
Да я понимаю. Spock Framework я сам пользовался для написания unit тестов, синтаксис куда более легковесный, чем в обычном JUnit (хотя под капотом используется именно он).

Я просто не понимаю помпы, с которой подается статья. Мы все делаем удобный для себя набор абстракций и mini-API для решения каких-то частных задач. Называть такой набор DSL и жаловаться на ограничения языка — ну это уж перебор. Хочешь свой язык и чтобы тебя ничего не ограничивало — ANTLR в руки :-)
Далеко не все делают для себя «удобный mini-API». Kotlin DSL это легкий способ и API в терминах предметной области получить, и сил затратить мало, так еще и такой подход полностью совместим с вашим Java кодом. Не стоит принимать «минусы» как жалобу, я хочу, чтобы у читателя было более объективное представление об инструменте до начала его использования. А про ANTLR для тестирования Java кода это вы отлично пошутили.
НЛО прилетело и опубликовало эту надпись здесь
Не шутил и не говорил такого. ANTLR — отдельно, Spock Framework со своим аккуратным синтаксисом — отдельно.
DSL — это, как мне кажется, чуть иная вещь, нежели библиотека/фреймворк под задачу. Это все таки — язык, со своим синтакисом и правилами.

Куда лучше рассматривать на роль DSL языки в Racket(например, тот же Scribble — DSL для оформления документов)
Непростая, но очень хорошая статья. При этом DSL'ы я не переношу, поскольку обычно они сводятся к «языку внутри языка», который понимает хорошо еще, если тот, кто его написал. Но примеры разобраны нетривиальные, и разобраны очень хорошо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий