Comments 56
Если честно, ситуацию по emacs Lisp прокомментировать не могу, т.к. ни разу его (emacs) даже не открывал.
По мне – есть пара пограничных случаев, когда создание DSL оправдало ожидания, хотя это, скорее, исключение из правил. Допустим wiki-разметка. Выстрелили как синтаксис, и как проект.
Но в целом, за исключением идеи «давайте забацаем личный ЯП» вариант возникновения в проекте DSL мне видится преимущественно следующим образом:
— существует некий текстовый формат хранения данных, специфичный для проекта
— постепенно он обрастает сущностями, которые начинают вырождаться в аюстракции, на которые вешают уже какой-никакой парсер.
— появляется необходимость в условных конструкциях и вуаля, новый ЯП, который надо учить.
По крайней мере, я такой процесс наблюдал уже пару раз, и честно говоря на этапе возникновения необходимости добавления условий, у меня как пользователя уже возникала мысль «почему бы просто не использовать дефолтную систему сериализации ЯП разработки?»
//! g=«SampleModeling» n=«Trumpet»
Bank 19 2 USER SMBrass/Trumpet
//! c=legato-light i=legato o=art:100
1 ART 1 Norm
//! c=legato i=accented-quarter o=note-hold:36,100
2 ART 2 Accent
//! c=legato i=cresc-quarter o=note-hold:37,100
3 ART 3 Fast cresc
//! c=legato i=legato-bowed o=note-hold:38,100
4 ART 4 PB up
//! c=legato-dark i=legato-bowed2 o=note-hold:49,100
5 ART 5 detashed
//! c=legato-dark i=legato-fast o=note-hold:50,100
6 ART 6 semi-legato
//! c=legato-light i=legato-portamento o=note-hold:36,100/note-hold:48,100
7 ART 7 chromatic
//! c=legato-light i=legato o=note-hold:37,100/note-hold:48,100
8 ART 8 mixed
//! c=legato-light i=legato-gliss o=note-hold:38,100/note-hold:48,100
9 ART 9 gliss1
//! c=legato-light i=legato-portamento o=note-hold:39,100/note-hold:48,100
10 ART 10 arabic
//! c=legato-light i=legato-portamento o=note-hold:40,100/note-hold:48,100
11 ART 11 pentatonic
//! c=legato-light i=legato-gliss o=note-hold:41,100/note-hold:48,100
12 ART 12 gliss1
Вообще там уже потихоньку оформляется своя сокращенная if-нотация. Правда работает пока через одно место))
www.softsynth.com/hmsl
— Что скриптование вообще не нужно? Безусловно, нет — оно было нужно.
— Что нужно было взять какой-то из стандартных языков? Очень вероятно, нет — стандартный язык с ходу тянет за собой толстую экосистему, привинтить которую надо ещё суметь, а затем обновлять её реализацию, зависеть от развития чужого проекта…
— Что надо было сразу покупать услуги толкового специалиста? Возможно, но если они не представляли себе вначале, куда и как развиваться и даст ли эта попытка какую-то практическую пользу, то не было причин считать, что такое привлечение окупится.
А вот что в данной ситуации однозначно надо было бы сделать — это, уже имея готовую нишу, адекватно доработать язык (или заменить!), чтобы получилось что-то, пригодное, условно говоря, на следующие 10 лет. И вот тут действительно нужен профильный специалист — хотя бы, чтобы разработать так, чтобы не повторять общеизвестные грабли популярных языков, и чтобы сделать качественный автоконвертер.
А будет тот язык просто уже известным, но с комплектом нужных библиотек, или своим — решится по месту.
Не надо бояться изменений. Надо бояться, наоборот, устареть.
Технологически. Но не по массе других факторов. Как интегрируется с основным приложением? (Не «как передать int в JS», а какие структуры строить, как их соединять, какие параметры давать пользователю, а какие вычислять самому, и т.д.) Как административно обеспечивать сопровождение движка, включая жалобы своих пользователей, импортировать обновления стоковой версии… и ещё масса проблем.
> Lua
> JavaScript
Вот именно, что я принципиально не хотел опошлять обсуждение до подобных деталей, по причинам см. выше в этом комментарии.
Не имеет большого значения, является ли этот исходный код DSL, sql или JavaScript.
И решая задачу через DSL мы, с большой вероятностью, выпускаем ЯП с детскими болезнями, последствия которых рано или поздно дадут о себе знать.
А вот взяв уже готовый язык со средствами его исполнения мы получаем, по сути, отлаженный инструмент, который может выдать нам удобоваримое AST которое привести во внутреннее представление нашего основного языка не составит большого труда. Этим решается проблема отвязки интерфейса от реализации.
И вот как получить из «удобного» языка AST я и хочу написать следующую статью (а может даже на две набежит).
Но с другой стороны, кто его знает, может DSL и правда пишет больно компетентный человек, который уже собаку на такой разработке съел)).
И поверьте — такой задачи, как выдать вам AST вообще обычно не стоит, по той простой причине, что для создания DSL это не нужно.
Ведь, в принципе, если в качестве DSL используется уже ЯП общего назначения, это скорее не DSL, а API. Разница, мне кажется, в том, что DSL – замкнутая система, а API находится в некотором домене, который диктует способы его вызова.
И согласен, что с AST меня занесло чутка: просто моя область интересов очень критична к рантайму (да и к памяти тоже, как правило), да и вообще основная буча происходит в лисенере 48000FPS)) Поэтому я несколько однобоко воспринял концепцию «внешнего языка» как, преимущественно, препроцессора.
Ну, это зависит от того, какой язык выбрать. Хотя гибкость в рамках одного языка конечно ограничена, но скажем что-то типа xml или sql внутри ЯП — вполне достижимо. Из практики — jscript, vbscript — в чистом виде API, эти языки не позволяют делать настоящий DSL. Но на groovy или скале уже пишется вполне нормальный DSL, синтаксис которого на первый взгляд не очень и похож на исходный.
Я и хочу в общем сказать, что изобретать свой собственный язык — не слишком хорошая идея, язык который хостится в другом языке, готовом — это как правило проще и удобнее с большинства точек зрения.
Плохая идея — делать то, в чём ты не разбираешься и не хочешь разобраться. А свой язык ничем не хуже своего класса и своей функции. Особенно смешно читать про JS. У eDSL есть не меньшее число неудобств. Навскидку:
- Необходимость всем знать много более сложный хостовой язык.
- Тысячи способов выстрелить себе в ногу самыми разными способами.
- Тормоза от интеркоммуникации между двумя разными рантаймами.
- Дикое потребление памяти виртуальными машинами.
- Сложности со многопоточной обработкой, интегрированной в общий пайплайн.
eDSL хорош только, когда у вас программа на каком-то языке и вам надо из него работать с какой-то предметной областью. Тогда вы не покидая привычного языка получаете дополнительное удобство работы с предметной областью.
Возможность применить, если вдруг стало нужно, намного более мощный язык — это достоинство, вообще-то. А необходимость его знать — это как бы требует подтверждения. Посмотрите на тот же kojo, и расскажите моей дочке, что ей нужно знать скалу, чтобы нарисовать квадратик при помощи Logo. Она и слова-то такого не знает, что характерно, для нее это лого.
Ну или gradle, или jenkins — его язык пайплайнов это eDSL на базе groovy. Я каждый день вижу, как люди на этом пишут, совершенно не вникая в то, что это groovy. Полезно знать? Да. Необходимо? В общем случае нет.
Так и с остальными пунктами, кстати. Я вполне верю, что ваш опыт отличается от моего, но в моей практике пункты 2-5 либо вообще места не имеют, либо их влияние сильно зависит от дизайна — то есть, оно под нашим контролем.
Было дело ковырялся я в билд-конфигах на груви. Больше не хочу.
Но если у вас доступа к другому языку нет — то как только возникает потребность, уже это становится настолько большой проблемой… и тогда у нее вряд ли вообще есть простое решение.
>Было дело ковырялся я в билд-конфигах на груви. Больше не хочу.
Ну, я вот тоже gradle считаю, скажем так, излишним на каждый день, но вообще-то в мире множество людей, которые тоже каждый день пишут на нем свои билд скрипты, и довольны.
Ну а то, что для ява-прогеров, груви после XML- это откровение, не удивительно.
Сколько вменяемых скриптеров под контакт ты знаешь? Каждый 5-ый музыкант или каждый 10005ый?
продублирую и сюда:
Всего интересующихся и пишущих, пожалуй, несколько сотен. Код которых видел лично – человек 20, вменяемый из них – один. И то, потому что он именно скриптер KSP до мозна костей. Общаться с ним как с программистом больновато. Вместо языка, в котором разберется любой, знающий предметную область, получился язык, на котором может хорошо писать только человек, который до глубины души выучил этот язык.
Один раз я еще видел очень хороший код, в библиотеке CinePianos (пианины), но не знаю, кто автор.
Вполне могу предположить, что это слабое свидетельство, основанное на личном опыте и конкретном кейсе.
Ну или gradle
Справедливости ради, maven, не смотря на xml, гораздо понятнее и проще для восприятия. Все потому, что у него есть четкая понятная структура. Это примерно как выбор из меню, против команд консоли.
Это достоинство, как уже сказал vintage, для профессионального программиста, который лезет в целевую область.
Для специалиста целевой области, который чуть-чуть программист — это не достоинство, а некартированное минное поле. Чем меньше ему требуется выходить за пределы того, что он знает и как думает, тем лучше для общего результата.
Общие принципы процедурного языка (порядок исполнения, группировки последовательностями, ветвлениями, циклами, предусловия и постусловия) — это неизбежно, но это максимум того, что нужно требовать из программистской специфики. И чем больше записано декларативно, тем лучше.
То есть, я когда говорю «лучше» — это в данном контексте нужно понимать как «проще в реализации», в первую очередь. То что у этого варианта есть свои недостатки — я и не спорю в общем-то.
>Чем меньше ему требуется выходить за пределы того, что он знает и как думает, тем лучше для общего результата.
Вы мне поясните, а зачем ему выходить? Вот мне часто приходилось слышать, что скала например сложный язык. И я по большей части с этим совершенно согласен. Но я также знаю, что в своей работе я ежедневно использую Spark Shell, который по сути внутри является Scala REPL. И мне почему-то совершенно не требуется выходить за пределы небольшого подмножества языка, где даже if или циклов по большому счету нет.
Тоже самое можно вполне применить к jenkins pipeline. Вы вполне можете писать пайплайны в декларативном стиле, вообще не понимая, что это groovy:
pipeline {
agent any
stages {
stage('Build') {
steps {
//
}
}
stage('Test') {
steps {
//
}
}
stage('Deploy') {
steps {
//
}
}
}
}
Ситуация: Петя написал скрипт. Петя профессиональный программист, скрипт соответствующе написан с залезанием в хитрые особенности, которые ему давно привычны.
Вася пытается пристроить этот скрипт себе, модифицировав по обстановке. Вася музыкант, понял что такое цикл, но вспоминать, например, тонкости применения this в JavaScript — у него мозг свернётся в трубочку.
Если в языке просто нет средств, которые можно поабьюзить далеко за пределами цели применения — Вася не будет выходить дальше того, что ему и понятно, и нужно. Если же они будут, то он с хорошей вероятностью откажется от использования скриптового средства просто потому, что он не в состоянии контролировать его опасность.
> И мне почему-то совершенно не требуется выходить за пределы небольшого подмножества языка, где даже if или циклов по большому счету нет.
Вы профессиональный программист. Вы можете не выходить за пределы минимально нужного вам подмножества, но вы психологически готовы выйти за его пределы по насущной потребности.
Именно этой готовности нет у большей части целевой аудитории профессиональной программы.
Мне это тоже психологически диковато, но я знаю о проблеме, на основании некоторого опыта общения с такими. И это включало даже старых программистов, которые успешно писали на чём-то типа Фортрана, но их жестоко вымораживал C. На родной кафедре таких одно время была чуть ли не половина.
Категорически — нет.
Это вы как раз получите универсальный язык с заточкой (скорее всего не в языке, а в библиотеке) под целевую область.
DSL же характерен не тем, что он может (и насколько он может выполнять эквивалент машины Тьюринга), а тем, что он не даёт сделать, в чём ограничивает (или хотя бы явно обозначает красными флажками). Именно потому, что он domain и specific.
Java, C#, Python и другие языки с AMM — DSL по сравнению с языками более низкого уровня с ручным управлением памятью (C/C++, Pascal и т.п.) Доменом является автоматическое управление памятью, ограничением — запрет на ручное управление.
Аналогично, пусть без автоматического управления, но с минимизацией игр с указателями, Fortran — DSL для записи математических расчётов.
Язык команд x86 является DSL по сравнению с языком микрокоманд конкретного Core Duo или Sandy Bridge. Доменом является переносимая система команд x86.
Декларативный язык является DSL по сравнению с процедурным языком. Доменом является поддержка описания зависимостей, условий и требований вместо ручного вычисления метода исполнения. Это в равной мере справедливо, например, для SQL и для Makefile. Можно то же сказать про HTML, хотя повальность JS портит картину.
Введение DSL, он же язык более высокого уровня, вызывается конкретным преимуществом его введения.
Типичными преимуществами являются:
* Независимость от особенностей реализации (как переносимость системы команд, написания на C или доступные индексы для СУБД).
* Устранение «геморроя», сиречь неприятных накладных расходов на реализацию. Характерный пример — ручное управление памятью.
* Необходимость вывести определённые сущности из ментального поля автора реализации. Уже работа с указателями доступна не всем программистам, а учитывать сочетаемость акций в АЛУ конкретной модели сможет десяток человек по всему миру.
И вот вопрос, как именно сделать, чтобы достичь преимущества для конкретной цели — и требует совместной работы высокоуровневых специалистов как в целевой области, так и в языках (чтобы не попасть на детские болезни). Решение методом внедрения широкораспространённого языка, хоть и с целевой библиотекой — решение тупое и далеко не всегда лучшее. Где-то вообще неуместен процедурный язык, а нужен декларативный, а где-то не подойдут конкретные фишки типа «в JS любое число — double», но специалист по языкам нужен хотя бы для того, чтобы знать, о чём спрашивать в плане поиска граблей.
Приводившийся здесь пример с FAR ужасен потому, что язык плагинов FAR — язык для программистов. DSL для расширения для не-программистов, пусть даже с базовыми свойствами языка программирования типа последовательностей действий, циклов, функций, и т.п. — должен быть максимально приближен к тому, как думает целевая группа, и избавлен от всех граблей пусть даже всемирно популярных языков. Поэтому всякие JS должны рассматриваться одними из последних (список его граблей не известен только тому, кто ленивее Емели с печи).
Чем ближе DSL к тому, как излагал бы свои задачи специалист целевой области, тем лучше. (Естественно, с поправкой на формализацию синтаксиса и выкидывание нецелевой лексики, где она используется.) Идеала никогда не будет, но надо стараться приблизиться к нему.
А все что дальше — уже зависит от того, насколько хорошо вы сформулировали требования к своему DSL, и насколько его достаточно самого по себе, без привлечения возможностей языка, в котором он хостится.
>Приводившийся здесь пример с FAR ужасен потому, что язык плагинов FAR — язык для программистов.
С каких это пор программистам не нужен DSL? Они тоже вполне себе ЦА для таких языков, и им он тоже необходим — причем как можно более полноценный. Поэтому и Lua.
>Категорически — нет.
Ну, я вас услышал, но меня вы не убедили. Возможно это решение не всегда лучшее — но оно практичное. Это работает, и это проверено многократно. И совершенно понятно, что сделать такой язык намного проще, чем спроектировать с нуля свой, и при этом не забыть ни одной фичи, которая будет впоследствии нужна кому-то.
Я такого не говорил и не предполагал. Я говорил, что DSL для программистов совсем другой, чем для пользователей специализированной программы.
> Вовсе нет, groovy это не DSL, это язык, на котором удобно делать DSL.
Повторюсь, проблема в том, что возможность выйти за рамки DSL, ограниченном в стиле того, как вы описали в примере с pipeline, даёт возможность, которая будет широко использоваться и отторгнет этим самым часть пользователей.
Может. Но мне кажется, собственный (как правило, ограниченный и достаточно примитивный) язык, который не позволяет делать что-то нужное, отторгнет еще быстрее.
Сможете вспомнить успешные примеры, когда DSL сделан как собственный язык, с нуля, а не как eDSL? Мне вот что-то такие вообще в голову не приходят — вспоминается либо groovy, либо Pyhton, либо Lua, либо Lisp в том или ином виде.
> какие структуры строить, как их соединять, какие параметры давать пользователю
Это нормальная программистская задача любого разработчика DSL. Она уже была успешно решена десятки, если не сотни раз.
Автор FAR специалист во множестве суботраслей программирования.
Но ожидать такого же уровня от авторов произвольной узкоцелевой программы как-то сложно.
> Это нормальная программистская задача любого разработчика DSL. Она уже была успешно решена десятки, если не сотни раз.
Успешно — наверно, десятки тысяч. И провально — сравнимо по количеству.
Ну, наверное да. Это разные специализации и это нормально.
У меня как-то на хабре возникала дискуссия на тему образования, нужно ли всех учить основам разработки компиляторов — грамматики там, AST, и т.п. темы. И мы не пришли к общему мнению. Для меня (из практики) это вполне рядовые задачки, хотя и не могу себя считать специалистом в области компиляторов. Но видел и мнение людей, которым это никогда не требовалось.
При этом для встраивания в свой проект DSL на условном groovy вообще не нужно быть специалистом по компиляторам — это совсем другая задача, она проще на порядки. Я только в своих проектах это делал наверное раз 5, не меньше.
>Успешно — наверно, десятки тысяч. И провально — сравнимо по количеству.
Если есть десятки тысяч успешных проектов, то по крайней мере всегда можно либо подсмотреть, как там сделано, либо позвать кого-то на помощь. Главное, что это не какой-то супер-пупер проект, который никто не знает, как делать.
LUA & SQLite добавляли энтузиасты уже после перехода FAR в open source.
Согласен, более чистые способы есть, см. коммент выше
DSL (domain specific language) — это значит что такой язык, который приспособлен к предметной области.
В частности например ноты — это DSL для музыкантов, а например конструкторская документация со всякими ГОСТами — это DSL для конструкторов.
С помощью таких DSL осуществляется передача информации между разработчиками, компьютер тут это несущественная сторона, которая проинтерпретирует DSL согласно правилам, и которому все равно какой поток байтов кушать. DSL создаются людьми для людей, и это самый главный факт.
То что в данном случае разработчики сделали такой DSL какой они сделали, говорит лишь об их некомпетентности как разработчиков-DSL, и ничего больше.
Если они пытались сделать язык общего назначения, то конечно лучше бы взяли готовый.
Ну а если бы они пытались сделать действительно DSL для музыкантов, то скорее всего они провалились, а язык общего назначения не помог бы в этой области.
Поэтому просто прокомментирую последнюю строчку, ответ на которую, в основном и предполагался статьей. Видимо, был чересчур категоричен)
Ну а если бы они пытались сделать действительно DSL для музыкантов, то скорее всего они провалились, а язык общего назначения не помог бы в этой области.
ну да, весь вопрос только в том, чтобы это так наз. «программирование» было доступно даже чайникам… Мне вот до сих пор не понятно как программируется вроде бы имеющий «дружеское» гуи логический редактор в кубе… ) Хоть и нужен он раз в год, но без талмуда там ни в зуб ногой ничего не понятно… Хотя пару раз я и за талмуд брался, но безрезультатно… А вот кубовский «программатор» экспрешн мэп интуитивно понятен и без талмудов, и любой чайник в нём может разобраться за полчаса.
Вы от хоста хотите столько наворотов, подвластных ЛИЧНО ВАМ :) Логично предположить, что вы сможете ему изъяснить свои желания на языке булевой алгебры. А то меня уже тут неделю брутфорсит человек, который хочет писать нотками миди во фруктах и получать на выходе «неотличимо от живаго». ;)
А разницы между текстовым интерфейсом и ГУИ принципиальной нет, как ни странно) Текстовые конфиги, тем более, всегда можно лицезреть в одной удобоворимой форме в любимом текстовом редакторе (vim там, или sublime text), а в гуи пока нужную кнопку найдешь....
что прям на русском языке можно писать? :) «Дорогой Кубэйс зпт сделай пжлст на пятом канале перевод 121-го контроллёра в програм чендьжъ номер 10!» :D
Или на каком? :cool:
У меня на англ. то времени нет, а ты хочешь чтобы я ещё и языком программирования занимался. Не серьёзно (для активно практикующих аранжировщиков :)) Нужно — открыл, на кнопочку назначил, работаем дальше. На «писанину» ох как много времени уходит…
а контактовский гуй и документация, конечно, русифицированы.
никто ж не говоит про ЯП. Просто пара строк с параметрами в соответствующий файлик (типа как мы пишем батники для серверов с веной, чтоб они сразу норм грузились и с нужными флагами)
Зуб даю, не глупый человек, профессионал с большой П, мне до него в некоторых вещах расти и расти. Только… Может ну их, музыкантов? Мне кажется, если б единственным вариантом облегчить себе жизнь было – писать динамическую библиотеку на C – я б все равно этим занимался, может просто чутка дольше))
Думается проблема в том, что на начальном этапе — свой ПРОСТОЙ язык — это хорошо, а когда он разрастается во что-то большое и при этом нестандартное -это уже ПЛОХО. Мы в лаборатории написали свой микроязык (да — DSL) для управления одновременно аналого-цифровым преобразователем и координатным устройством (с парсингом, и т.п...). Там команд с гулькин нос и они все умещаются на половине листа А4 крупным шрифтом. И (ура!) это творение не надо развивать. Оно вполне самодостаточно. Там задействовано одно АЦП и один конкретный координатник (что-то типа станка с ЧПУ). Стандартные ЯП включают в себя некие свойства обобщения — которые в нашем случае излишни.
Вообще мир музыки — непочатый край странных кейсов программирования. Там, покопавшись, можно ещё и не такое найти (один движок FL Studio, написанный на Delphi чего стоит).
Кстати, была ещё такая штука — NI Reaktor, которая позволяла клепать свои инструменты вообще с нуля на (если мне не изменяет память) графическом ЯП. Что с ним стало сейчас, правда, не слежу. Но уже тогда эта фиговина казалась абсолютным оверкиллом, в котором на практике что-то собрать было довольно трудно.
Но вопрос интересный. Какой язык предоставить музыканту, знакомому с модульным синтезом, но не с программированием? У меня подозрение, что граф. программирование в духе Reaktor или Max/MSP здесь будет предпочтительнее какого-нибудь JavaScript.
Можно согласиться с следующим положением: невежество, дилетантизм в области простроения языков наносит вред проекту. В качестве встраиваемого языка лучше сначала рассмотреть готовое решение: Lua, Scheme, Python и так далее.
Здесь вспоминаются русскоязычные движки для текстовых игр. Существовал целый ряд проектов, авторы которых, судя по всему, получали удовольствие от начального создания собственных ЯП, а затем, по прошествии времени, уже с тоской и нежеланием поддерживали и расширяли свои языки. И вот в какой-то момент такие самоделки-долгострои сходу опередил по уровню реализации проект, где в качестве встроенного фигурировал обычный язык Lua.
При этом определенные предметные области вполне заслуживают создания DSL. Особенно, если нотация получается декларативной, не тьюринг-полной. Раз уж исходно был взят музыкальный контекст, то здесь можно вспомнить язык LilyPond. Он, с одной стороны, является декларативным («с4 e g e c»), а с другой — расширяется с помощью Scheme.
Здесь любопытно, что та же Lua — это как раз пример DSL (миниязык для встроенных применений), который кто-то за нас уже написал. В своей работе, вы, возможно, используете и иные «чужие DSL»: make, TeX, graphviz и так далее.
Кроме того, собственный DSL может быть разумным решением, если того требуют определенные условия функционирования встроенного языка. В своей заметке автор пишет по поводу Reaper: «в итоге там, где можно, продублировала свой ЯП JSFX(ReaScript) в виде API для C++, lua и Python». Тут явная путаница. В Reaper используется тот же Python для задач автоматизации редактирования на уровне piano roll. А вот собственный DSL JSFX, который напоминает Си, был создан для задач обработки аудио и MIDI в реальном времени. Язык, к сожалению, тоже отдает дилетантизмом, но, с другой стороны, а где было взять готовый небольшой встраиваемый DSP-язык для работы в реальном времени?
Подводя итог. Разработка DSL — задача, которая требует определенного опыта и знаний. Причем, подобные знания, во многом, за пределами типичных университетских курсов по теории компиляторов.
Заголовок:
Не создавайте собственный ЯП (DSL) для расширения функционала приложения
Первый абзац:
Когда вы хотите дать пользователю возможность писать плагины для своего приложения, вы встаете перед выбором того, как предоставлять API. Под катом я покажу, почему худшим решением для этого будет изобретение собственного языка программирования и парсинг исходников, а также причем здесь мебель.
Так вот. Писать плагины для приложения — это одно. Расширять функциональность — это другое (не всегда, но часто). Заставлять людей пользоваться вашим DSL для написания плагинов — не очень хорошо. Использовать DSL для автоматизации и расширения вашего приложение — нормальная здравая идея.
Проще говоря, DSL — это инструмент, у которого есть набор полезных применений, и его, как и любой инструмент, надо правильно применять.
Просто мне архитектурно кажется, если есть такая возможность, то, скорее всего, есть некая точка подключения, которая грузит сторонние модули (или плагины) и работает с ними. Тот же SublimeText или vim.
Вот в браузерах я так и не понял: есть плагины, а есть расширения, чем они конструктивно (или идеологически) отличаются?
С помощью этого язык расширяют необходимой функциональностью создавая DSL вариант средствами доступными в базисе языка.
P.S. Тот же HSML, приведённый выше, построен в качестве расширения исходного Форт языка и скорее всего подгружается как расширение, но бывают и другие схемы интеграции Форт реализованных в разных языковых базисах.
Расширение Форт языка может превратить его в синтаксически/семантически другой язык.
А можно для общего развития пример расширения функциональности (сторонним пользователем), не являющимся плагином?
Самый простой пример — это макросы в Excel. Ну и вообще любая внутренняя автоматизация в системах, которые дают такую возможность.
На встроенном языке 1С пишут разнообразные приложения и не только для решения бизнес-задач. Разнообразие встроенных объектов платформы позволяет писать на 1С наряду с бухгалтерией, торговлей и зупом такие приложения как шина данных. И вот уже на встроенном языке написаны конфигурации с объемом кода, сопоставимом с таковым, если бы теже задачи решались на языке общего назначения. На встроенном языке уже начинают решать задачи, которые выходят за рамки DSL, изначально декларованного для платформы.
Все это приводит к тому, что уже возникает потребность в развитии встроенного языка, т.к. его изначальная простота не позволяет строить сложные надежные приложения. И здесь мне видятся два пути развития:
1. всю функциональность, потребность в которой выражена в виде реализованного функционала на встроенном языке, нужно переносить во встроенные объекты платформы и т.о. возвращать первоначально назначение встроенного языка;
2. развивать встроенный язык до уровня языка общего назначения.
Последний вариант, как и показано в статье, ведет в никуда. В этом варианте фактически DSL перестает быть таковым и теряется главное его преимущество — не решать алгоритмические задачи, а решать задачи предметной области.
Не создавайте собственный ЯП (DSL) для расширения функционала приложения