Создание DSL против встраивания существующего языка

Question

Это часто возникает: ваше приложение стало достаточно обширным, и пришло время добавить в него некоторую программируемость, чтобы сделать его гибким. Одним из примеров может быть приложение для финансирования - вы хотите добавить редактор формул, чтобы вы могли создавать свои собственные формулы без необходимости повторной компиляции кода.

Вы должны сделать выбор: создаете ли вы свой собственный токенизатор, парсер и интерпретатор/цепочку компилятора, что может занять много времени и может быть сделано неправильно? Или вы просто вставляете другой язык сценариев, у которого есть проблема, что он, вероятно, раздует ваш код и подвергает ваше приложение уязвимостям безопасности.

Как бы вы отбалансировали компромиссы и приняли это решение?

Answer 1

Отказ от сделки - внедрить проверенный, хорошо документированный интерпретатор. В противном случае у вас будет такая мерзость, как MAXScript.

Answer 2

Я бы создал свой собственный интерпретатор, используя существующий генератор синтаксического анализатора (например, ANTLR или комбинаторы парсеров Haskell/Scala). Это действительно не так сложно, как все это, и для простых языков это очень легко. Я создаю реализацию для дьявольски простой DSL днем, и она отлично работает в первый раз (без ошибок).

С учетом этого вы не хотите создавать собственный язык Turing Complete. Если ваши потребности настолько сложны, вы, вероятно, должны включить язык сценариев. Если вы работаете в JVM, JRuby и Clojure являются отличными кандидатами на подобные вещи, особенно учитывая их собственные преимущества в области внутренних DSL.

Answer 3

Как насчет плагина? Существует несколько преимуществ:

• Позвольте разработчикам-заказчикам разрабатывать среду, в которой разрабатывается исходное приложение.
• В современных разработчиков. платформ, вы получаете большой контроль и безопасность через контракты на программное обеспечение.
• Если он спроектирован правильно, вы можете правильно обвинить раздувание и повреждение подключаемого модуля, вызвавшего его, - как это делает Chrome, когда Flash или другой подключаемый модуль третьей стороны выходят из строя.
• Легко добавить дополнительную защиту посредством лицензирования/сертификатов.
• Легко объединить подключаемый модуль с приложением, если это потрясающе, и вы хотите, чтобы все ваши клиенты имели его.

Answer 4

Если DSL достаточно прост, что синтаксический анализатор/интерпретатор подходит для одной страницы, я бы рекомендовал внедрить существующий язык сценариев.

Я недавно провел несколько месяцев, работая над проектом, который я унаследовал, который содержал полностью родной язык сценариев. Я потратил много времени на понимание интерпретатора синтаксического анализатора &, чтобы я мог исправить ошибки, сделать его потокобезопасным, расширить его, оптимизировать. Кроме того, было время, чтобы узнать и понять причуды этого нового языка сценариев, которые были почти такими же, как и другие, которые я уже знал. Я бы предпочел использовать это время для встраивания существующего языка, такого как Ruby или Lua, и настройки его в соответствии с нашими потребностями.

Пользователь пользовался бы языком, на котором было легче программировать, с меньшими причудами и ошибками. Я бы воспользовался более глубоким пониманием внутренних компонентов хорошо продуманного популярного языка, вместо того, чтобы получать относительные бесполезные экспертные знания в «myScript».