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

Question

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

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

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

Answer 1

Сделок нет - вставьте тщательно проверенного, хорошо документированного интерпретатора. В противном случае вы получите мерзость, подобную MAXScript.

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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