Comments 10
Чувствовали такое когда-нибудь? Когда вы приходите писать Gradle-файл, в самом начале, вы не понимаете, что в нем есть, и нужны какие-то примеры.
Не суйте DSL’и во все щели, пожалуйста.
Это, пожалуй, лучшее в статье. Хотел в комментарии написать это же.
А вот тут хотелось бы подискутировать! То есть, жуткий адь в Мавене вас таки полностью устраивает?
Есть идея, что любая достаточно выделенная предметная область образует свой язык. И либо ты делаешь красивый DSL на удобных инструментах, либо делаешь то же самое, но завуалированно, например натянув глобус на сову, или что угодно на XML, или куда хуже — на JSON или Yaml без схемы
Есть идея, что любая достаточно выделенная предметная область образует свой язык. И либо ты делаешь красивый DSL на удобных инструментах, либо делаешь то же самое, но завуалированно, например натянув глобус на сову, или что угодно на XML, или куда хуже — на JSON или Yaml без схемы
DSL удобен и полезен, когда вам надо описывать сложную структуру данных. Именно, что описывать — самому, руками. Там, где такой потребности нет, там и DSL не так чтоб нужен. Какой бы выделенной не была предметная область.
В естественных языках есть такая штука — номинализация. Действие можно описать как предмет.
Опять же, если взять LISP, то у нас есть свойство гомоиконности. Если мы «программируем на Yaml», то оно дается нам автоматически — просто вместо компилятора трансляцией из предметный области в AST занимаемся мы сами, наш мозг)
То есть, в любом достаточно продвинутом языке, сложную структуру процессов можно описать как структуру данных. В каком-то случае такую запись можно будет назвать «декларативной».
И наоборот — можно деноминализировать структуру данных в набор действий. Например с помощью паттерна Builder.
Таким образом, действия и данные на каком-то уровне абстракции языка могут быть взаимозаменяемыми.
И ваше предыдущее предложение превращается в: «DSL удобен и полезен, когда вам надо описывать что-то достаточно сложное.»
Ну вообще да, программисты затем и нужны, чтобы решать сложные задачи :-) Где нет такой потребности, программисты не нужны.
Опять же, если взять LISP, то у нас есть свойство гомоиконности. Если мы «программируем на Yaml», то оно дается нам автоматически — просто вместо компилятора трансляцией из предметный области в AST занимаемся мы сами, наш мозг)
То есть, в любом достаточно продвинутом языке, сложную структуру процессов можно описать как структуру данных. В каком-то случае такую запись можно будет назвать «декларативной».
И наоборот — можно деноминализировать структуру данных в набор действий. Например с помощью паттерна Builder.
Таким образом, действия и данные на каком-то уровне абстракции языка могут быть взаимозаменяемыми.
И ваше предыдущее предложение превращается в: «DSL удобен и полезен, когда вам надо описывать что-то достаточно сложное.»
Ну вообще да, программисты затем и нужны, чтобы решать сложные задачи :-) Где нет такой потребности, программисты не нужны.
И ваше предыдущее предложение превращается в: «DSL удобен и полезен, когда вам надо описывать что-то достаточно сложное.»Да, вы совершенно правы, фиксация на данных была не совсем корректна.
Таким образом, действия и данные на каком-то уровне абстракции языка могут быть взаимозаменяемыми.
Возможно, как пример тут уместно будет упомянуть два подхода к построению UI, когда он создается процедурным способом (через вызовы CreateButton, CreateLabel и т. п.) и когда он описывается декларативно (HTML и все вариации, а также применялось когда-то в Delphi). В данном случае DSL — это декларативный язык, на котором описывается UI, и практика показывает, что он значительно удобнее.
Возможно, как пример тут уместно будет упомянуть два подхода к построению UI, когда он создается процедурным способом (через вызовы CreateButton, CreateLabel и т. п.) и когда он описывается декларативно (HTML и все вариации, а также применялось когда-то в Delphi). В данном случае DSL — это декларативный язык, на котором описывается UI, и практика показывает, что он значительно удобнее.
То есть, жуткий адь в Мавене вас таки полностью устраивает?
Что-то слишком радикально) Я не писал, что gradle плохой, а maven хороший. Все сильно от задачи зависит. Но у мавена помимо гадкого xml есть и преимущество, у него есть понятная структура. Ты знаешь чего с чего начать, примерно помнишь какие есть блоки, все, дальше IDE тебе дает возможные варианты и ты выбираешь все что нужно. И для простых проектов это вот отлично. Грэдл добавляет гибкости и мощи, но при этом непонятно как это реализовать. И если ты не пишешь каждый день грэдл конфиги, то лезешь искать примеры того, что нужно.
делаешь красивый DSL на удобных инструментах
Штука в том, что часто красиво это может быть только для автора DSL. А для остальных может быть не очевидно и дальше путь в документацию. И, как написано в статье, хорошо если она есть и понятно написана.
Так автодополнение в IntelliJ IDEA должно работать по Kotlin DSL, разве нет?
> красиво это может быть только для автора DSL
не нравится DSL — не используй его. Точно так же, как не нравится Java или Kotlin — пиши на чем нравится. Все как всегда)
> красиво это может быть только для автора DSL
не нравится DSL — не используй его. Точно так же, как не нравится Java или Kotlin — пиши на чем нравится. Все как всегда)
Так автодополнение в IntelliJ IDEA должно работать по Kotlin DSL, разве нет?
По разному работает. Примерно как выбор из меню (по xsd схеме) для мавена и командная строка (с подсказками) для грэдл.
не нравится DSL — не используй его
Не всегда это возможно. Вот не нравится мне груви, например, в грэддл, какие у меня варианты?
Ну это уже совершенно другая история. Когда кто-то принял решение за тебя (например, на работе был важный митинг о судьбе проекта, а ты в нем не участвовал) — что посоветовать? Кусать локти и в следующий раз ходить на митинги и форсировать на них свое мнение? Уволиться? Тут та же фигня — ты пропустил тот митинг, когда определяли дизайн мавена.
Sign up to leave a comment.
Kotlin DSL: Теория и Практика