Или посчитать строки в файле:

Философия UNIX состоит в том, чтобы использовать несколько или эти маленькие утилиты и объединять их для выполнения самых удивительных и сложных задач. Например, вы можете взять входной файл, преобразовать его с помощью sed, а затем распечатать выбранные детали, используя gawk .

5. Огурец — DSL для определения функциональных тестов.

Огурец — это DSL для определения функциональных тестов. У него очень гибкий синтаксис, благодаря которому он выглядит почти как свободный текст. По сути, разработчики, аналитики и клиенты могут сидеть за столом и определять некоторые сценарии. Затем эти сценарии будут выполняться как тесты, чтобы проверить, соответствует ли приложение ожиданиям.
Вот как мы можем определить ожидания для снятия с банкомата:

Мне очень нравится этот DSL, потому что планка его использования очень низкая. Однако этот DSL требует от разработчика определения некоторого кода с использованием GPL. На практике это работает так, что разработчик определяет конкретные команды, такие как: «{name} имеет {amount} $ на своем аккаунте» и определяет код, который выполняет эту команду в GPL, выбранном для проекта (Ruby, Java или другие поддерживается). После того, как разработчики создали эти команды, специфичные для интересующего приложения, все пользователи могут использовать их при определении своих функциональных тестов. Также возможно начать другим способом: сначала вы пишете свои сценарии, как хотите, пытаясь зафиксировать требования, и только позже разработчики сопоставляют каждую команду с соответствующей функцией в GPL.

Другими словами, этот DSL отлично подходит для сокрытия реального кода за поверхностью, понятной каждому, и каждый может внести свой вклад. Намного лучше сидеть за столом и обсуждать с представителем банка, используя пример, который мы показали, чем показывать ему сотни строк Java, которые соответствуют этим командам, верно?

6. Website-spec — DSL для функционального веб-тестирования

Огурец — не единственный DSL, используемый для определения тестов. Спецификация веб- сайта может использоваться для определения функциональных тестов, специфичных для веб-приложений.
Здесь мы определяем, как перемещаться по определенному веб-сайту и что мы ожидаем найти.

В этом случае нет необходимости для разработчика определять перевод команд в GPL, потому что этот язык использует доменные команды, такие как «Click», которые интерпретатор знает, как выполнять. С минимальным обучением теперь каждый может описать конкретное взаимодействие с сайтом и ожидаемые результаты. Довольно аккуратно, а?

7. SQL — базы данных

Вы, наверное, слышали о SQL. Это язык, используемый для определения того, как вставлять, изменять или извлекать данные из реляционной базы данных. Давайте посмотрим статистику из таблицы STATS :

Конечно, вы не ожидаете, что среднестатистический Джо сможет писать сложные запросы: SQL не является тривиальным языком и требует некоторого времени для освоения. Однако вам не нужно обучаться как разработчику, чтобы изучать SQL. Действительно, многие администраторы баз данных не являются разработчиками. Возможно, Джо не следует доверять доступ на запись в базу данных, но он может получить доступ для чтения и писать простые запросы, чтобы отвечать на свои вопросы, вместо того, чтобы спрашивать кого-то и ждать ответа. Предположим, ему нужно знать максимальную температуру в августе в Атланте:

Возможно, Джо никогда не достигнет уровня администратора, но он может выучить несколько базовых запросов и адаптировать их к своим потребностям, сделав его более независимым и позволяя коллегам сосредоточиться на своей работе, а не помогать ему.

8. HTML — веб-верстка

Я действительно надеюсь, что вы слышали об этом довольно успешном языке для определения документов. Удивительно думать, что мы могли определять HTML-страницы 20 лет назад, когда большинство людей подключали настольные компьютеры к мониторам с разрешением 640 × 480 пикселей, и теперь эти некоторые страницы можно отобразить в браузере, который работает на наших смартфонах. Я думаю, это хороший пример того, чего можно достичь с помощью DSL.

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

9. CSS — стиль

Язык Cascading Style Sheet определяет стиль, используемый для визуализации документа. Мы можем использовать его, чтобы определить, как HTML-документ будет отображаться на экране или как он будет отображаться при печати.

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

10. XML — кодировка данных

Несколько лет назад XML казался решением всех проблем в ИТ. Теперь шумиха давно прошла, но XML здесь, чтобы остаться. Надежный DSL для представления данных и достаточно гибкий.

Хотя это не самый читаемый или впечатляющий язык, каждый может изменить данные, содержащиеся в файле XML.

11. UML — визуальное моделирование

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

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

12. VHDL — аппаратный дизайн

VHDL — это DSL, используемый для определения цепей. Когда-то инженеры-электронщики раньше проектировали сложные системы, непосредственно решая, какие ворота использовать и как их соединить. VHDL изменил все это, предоставив концепции более высокого уровня, которые эти инженеры могут использовать для определения своих систем.

Пример взят из Википедии .

Существуют инструменты, способные обрабатывать эти определения для получения фактических схемных схем, готовых к печати. Verilog — это еще один DSL, похожий на VHDL.

13. ANTLR — определения лексера и парсера

ANTLR поставляется с собственным DSL для определения грамматик лексера и синтаксического анализатора. Это инструкции по распознаванию структуры фрагмента текста.
Например, это небольшой фрагмент грамматики лексера:

JavaCC, Lex, Yacc и Bison — похожие инструменты, и все они поставляются с немного отличающимся DSL, вдохновленным формой Backus-Naur .

14. Make — сборка системы

Make — это язык, который описывает, как что-то построить, и зависимости между различными этапами. Например, вы можете определить, как создать исполняемый файл и указать, что для этого вам сначала понадобятся 3 объектных файла. Затем вы можете определить для каждого из этих объектных файлов, как получить его из соответствующего исходного файла.

В этом примере мы указываем, что для создания программы myExecutable нам понадобятся объектные файлы, и как только мы получим их, мы будем использовать gcc для их соединения.
Мы также можем определить некоторые константы в верхней части файла, чтобы потом было проще изменить Makefile, если он нам понадобится.

15. Латекс — макет документа

Латекс часто используется в академии и в издательской индустрии для производства великолепных бумаг и книг.

Как только вы описали документ в этом формате, вы обычно генерируете PDF.

Это очень хорошо, потому что он может обрабатывать ссылки на рисунки или таблицы, он может автоматически их нумеровать, это позволяет вам очень сложно управлять расположением таблиц. Если вы хорошо владеете LaTeX, вы можете получить довольно хорошие результаты.

16. OCL — модельные ограничения

OCL расшифровывается как Object Constraint Language, и его можно использовать для определения дополнительных ограничений на объекты. Обычно он используется вместе с UML.
Например, если у вас есть класс Appointment с двумя свойствами start и end, вы можете указать, что конец встречи следует за ее началом :

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

17. XPath — выбор узлов XML

XPath может использоваться для выбора узлов в документах XML. Например, предположим, что у вас есть документ, представляющий список ресторанов, и вы хотите получить последний ресторан:

Выражения XPath используются в XSLT для определения элементов для преобразования или могут использоваться в сочетании со многими библиотеками для всех типов языков, чтобы определить, какие элементы следует извлечь из документа. Если вам интересно, что такое XSLT, это язык для определения преобразований XML-документов.

18. BPEL — Бизнес-процессы

BPEL — это язык для определения взаимодействия между веб-сервисами для реализации бизнес-процессов. Раньше он был более популярным, когда мир проходил фазу сервис-ориентированной архитектуры (SOA).

Цель этого языка — позволить архитекторам программного обеспечения или даже аналитикам комбинировать различные веб-сервисы или другие компоненты для получения сложных систем.

Существуют разные реализации языка, каждая из которых имеет свои расширения и в основном несовместима одна с другой.

19. Actulus Modeling Language — DSL для расчета страхования жизни и пенсий

Этот пример взят из статьи «Актуарный язык программирования для страхования жизни и пенсий» Дэвида Кристиансена и соавт.
Этот DSL указан в Списке языков для конкретного финансового домена, где вы можете найти еще много похожих примеров.

---

Так для чего мы можем использовать DSL?

Посмотрев на эти примеры, мы можем сделать вывод, что DSL могут использоваться для различных целей:

• определить команды для выполнения: например, sed или gawk
• описать документы или некоторые их специфические аспекты: например, HTML, латекс или CSS
• определить правила или процессы: например, BPMN или Actulus

Это лишь некоторые типичные случаи использования, но DSL могут использоваться по многим другим причинам.

Также важно отметить, что DSL фокусируются на одном конкретном аспекте системы, и часто имеет смысл объединять несколько из них для описания различных аспектов продукта. Например, HTML и CSS используются вместе для описания содержимого и стиля или документа, XML и XPath используются для определения данных и способов их прохождения. OCL используется для определения ограничений на модели UML.

Можно подумать о разработке не одного DSL, а семейства или взаимосвязанных DSL.

Хорошо, на данный момент вы должны иметь некоторое представление о том, как может выглядеть DSL и для чего его можно использовать. Теперь давайте посмотрим, почему вы должны использовать один, а затем, как его создать.

DSL против GPLS: 5 преимуществ использования доменных языков

Вы могли бы задать себе следующий вопрос:

Зачем использовать конкретный, ограниченный язык вместо общего, мощного?

Короткий ответ — доменные языки ограничены в том, что они могут делать, но из-за своей специализации они могут делать гораздо больше в своем собственном ограниченном домене.

Давайте будем конкретными и увидим пять отдельных преимуществ:

1. Мы можем анализировать их гораздо лучше: хотя на практике невозможно гарантировать, что программа, написанная на C или Java, будет соответствовать определенным характеристикам (например, не заканчиваться в бесконечном цикле), мы можем выполнять любые анализы, когда используем DSL. Именно потому, что они ограничены в своих возможностях, их легче анализировать.
2. Они более безопасны. Меньше вещей может пойти не так при использовании DSL. Когда в последний раз вы имели исключение нулевого указателя при работе с HTML или SQL? Точно, никогда. Это очень важно, если мы делаем что-то критическое, например, занимаемся здоровьем человека или его деньгами.
3. При наличии ошибок это ошибки, характерные для домена, чтобы их было легче понять. Они специфичны для предметной области: поэтому ошибки связаны не с нулевыми указателями, а с вещами, которые может понять специалист по предметной области.
4. Это также означает, что интерпретация проще, поэтому перенести их на новую платформу легко. То же относится и к симуляторам. Те же самые HTML-документы, которые мы могли открыть на КПК в 2000 году, теперь можно открыть на iPad Pro.
5. Мы можем научить их более легко: они ограничены в объеме, поэтому требуется меньше времени и меньше обучения, чтобы овладеть ими просто потому, что есть меньше вещей для изучения.

Зачем принимать доменные языки?

Итак, мы увидели, что такое доменные языки и чем они отличаются от GPL, теперь мы должны понять, почему мы должны рассмотреть вопрос о принятии их. Каковы реальные преимущества?
Специфичные для домена языки хороши тем, что:

1. Они позволяют вам общаться с экспертами в области . Вы пишете медицинские приложения? Врачи не понимают, когда вы говорите о массивах или циклах , но если вы используете DSL для пациентов, температурных показателей и артериального давления, они могут понять это лучше, чем вы.
2. Они позволяют вам сосредоточиться на важных концепциях. Они скрывают реализацию или технические детали и предоставляют только ту информацию, которая действительно имеет значение.

Они являются отличными инструментами для поддержки рассуждений по конкретным доменам, и все остальные преимущества вытекают из этого. Давайте посмотрим на них в деталях.

Общение с экспертами в области

Во многих случаях вам нужно создавать программное обеспечение вместе с экспертами в предметной области, которые сами не являются разработчиками.
Например:

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

Теперь проблема состоит в том, что эти эксперты по предметной области не имеют опыта разработки программного обеспечения, и способы общения разработчиков и экспертов по предметной области могут быть очень разными, потому что они говорят на разных языках.

Разработчики говорят о программном обеспечении, в то время как эксперты домена говорят об их домене.

Создавая DSL, мы создаем язык для общения между разработчиками и экспертами в предметной области. Это не слишком отличается от того, что описано в Domain Driven Design . Разница здесь в том, что мы хотим создать язык, понятный разработчикам, экспертам в области, а также программному обеспечению, которое сможет выполнять инструкции, указанные в DSL.

Теперь Святой Грааль должен был создать язык, передать его экспертам в области и заставить их уйти и написать свои запросы или логику в одиночку. На практике обычно DSL не достигают этого, но в любом случае оказываются очень полезными: типичное взаимодействие заключается в том, что эксперт по предметной области описывает, что он хочет для разработчика, и разработчик может немедленно записать это описание, используя DSL. Эксперт в области мог бы в этот момент прочитать его и критиковать .

Обычно не разработчики не обладают аналитическим умением формализовать проблему, но они все равно могут прочитать и понять ее , если она написана на DSL с использованием языка, знакомого с пользователем. Кроме того, эти инструменты могут использовать симуляторы или запускать запросы на лету, чтобы эксперт по доменам мог смотреть не только на сам код, но и на результат.

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

Используя DSL, вы можете очень часто:

• Наличие экспертов в области чтения или написания тестов высокого уровня. Как требования, которые выполняются
• при совместной разработке с экспертами в предметной области разработчики могут получать отзывы в очень быстром темпе

Итак, ответ на вопрос:

Могут ли эксперты в области (не программисты) писать только DSL?

Это, конечно, «это зависит». Но определенно DSL позволяют привлекать экспертов по предметной области к процессу разработки . Резкое сокращение циклов обратной связи и экспоненциальное снижение рисков дисбалансов. Вы знаете, когда разработчики пару раз общаются с экспертами по доменам, они уходят и возвращаются, чтобы показать свое решение экспертам по доменам. И эти эксперты смотрят на решение и заявляют, что оно абсолютно, полностью, бесповоротно неправильно. Вы можете избежать этого, используя DSL.
Поэтому важно понимать преимущества этого, и в то же время быть реалистичным. Видите ли, несколько десятилетий назад некоторые энтузиасты предлагали, чтобы разные люди могли писать запросы на SQL автономно:

Сорок лет спустя становится ясно, что домохозяйки не собираются писать SQL.
Дело в том, что многим DSL требуется формализовать процессы так, чтобы они требовали значительных аналитических навыков. Эти навыки легко найти у разработчиков, но не так часто встречаются у людей с не научным образованием.

Фокус и производительность

Тот факт, что DSL абстрагируют некоторые технические детали, чтобы сосредоточиться на знаниях, которые нужно захватить, имеет важные последствия.

С одной стороны, это делает инвестиции в код, написанный с использованием DSL, чем-то, что сохраняет ценность с течением времени . По мере изменения технологии вы можете изменить интерпретатор, обрабатывающий код DSL, но код DSL может остаться прежним. HTML-страницу, написанную 20 лет назад, все еще можно открыть с помощью устройств, которые никто не мог представить 20 лет назад. Тем временем браузеры были полностью переписаны несколько раз. Тогда логику можно перенести на новые технологии.

Я хочу поделиться историей о компании, с которой я работал. Эта компания создала собственный DSL для определения логики для бухгалтерских и налоговых расчетов. Они начали создавать этот DSL 30 лет назад и в то время использовали для создания консольных приложений. Да, приложения, работающие на консолях размером 80 × 25 ячеек. Я работал с ними над реинжинирингом компилятора, и тот же код их DSL теперь используется для генерации реактивных веб-приложений. Как это случилось? Поскольку DSL захватил только логику, действительно ценную часть программ , чрезвычайно важный для компании актив. Технические детали были обобщены в компиляторе. Поэтому нам просто нужно было изменить компилятор DSL, чтобы сохранить ценность логики и сделать ее пригодной для использования в более современном контексте.

Это учит нас тому, что:

Доменная логика — это то, что имеет ценность и должно быть сохранено, в то время как технологии меняются со временем

Используя DSL, мы можем отделить доменную логику и технологию и заставить их развиваться отдельно.

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

Типичные (неправильные) причины против DSL

Есть много разработчиков, которые думают:

Если мой язык закончен по Тьюрингу, я могу делать с ним все

Да и нет. Вы можете решить любую проблему, но не обязательно:

• написать наиболее краткое и четкое решение проблемы
• вы не можете написать решение быстро
• Вы не можете написать решение, которое понятно
• Вы не можете предоставить ошибки, которые понятны
• Вы не можете показать это и обсудить это с экспертами домена
• Вы не можете обеспечить поддержку инструмента, которая имеет значение для рассматриваемой проблемы
• насколько многократно используется решение: если вы напишите его на C, вы не сможете использовать это решение в другом контексте. С DSL вы можете начать с создания решения один раз, а затем создать несколько генераторов или интерпретаторов кода.
• DSL в действительности может быть быстрее, потому что генератор может быть специализирован для определенной архитектуры

Но люди должны будут выучить другой язык

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

Но я был бы заперт в DSL!

У меня есть несколько шокирующих новостей: вы уже заперты на любом языке программирования, который используете для выражения логики своих систем. Если эти языки перестанут развиваться, вам нужно будет разобраться. Сколько компаний попали в ловушку своих кодовых баз Cobol, Visual Basic или Scheme? Разница в том, что, если вы заблокированы в языке, который вы создаете и контролируете, вы можете решить, будет ли язык развиваться, если компилятор может ориентироваться на новую среду («давайте сгенерируем веб-приложение вместо консольного приложения!») , Если вы заперты на чужом языке, вы ничего не можете с этим поделать.

DSL не будет достаточно гибким

Проектирование DSL требует четкого определения его объема. Будут пропущены некоторые вещи, которые вы могли бы иногда делать, но которые DSL не будет поддерживать. Почему это? Поскольку DSL должен быть конкретным и ограниченным, для отличной поддержки множества задач, которые должны быть исключены другие. Правильный баланс — одна из самых больших проблем, с которой вы столкнетесь при разработке DSL, но если вы все сделаете правильно, вы сможете охватить все разумные случаи использования DSL. Часто можно спроектировать DSL, расширяемый, поддерживающий функции, написанные на GPL, в случае, если они действительно очень нужны. Но это следует рассматривать как способ успокоить пользователей, пока они не поймут, что они будут крайне редко в этом нуждаться.

Сборка DSL требует огромных усилий

Это просто неправда, если вы используете правильный подход. В следующем разделе мы рассмотрим различные способы создания языков и все необходимые вспомогательные инструменты с разумными усилиями.
Вы можете найти список других предполагаемых препятствий для принятия DSL здесь: Камни преткновения для языков, специфичных для предметной области, или вы можете прочитать эту статью, которую я написал в соавторстве о преимуществах и проблемах с принятием моделирования в целом (в основном это относится и к DSL).

Как создавать доменные языки

Чудесно, вы уже поняли, почему предметно-ориентированные языки такие крутые и какие преимущества они могут принести вам.
Теперь есть только один вопрос:

Как мы строим DSL?

Давайте посмотрим, как, посмотрев на:

• какие инструменты вы можете использовать для создания DSL
• Каковы наиболее важные факторы успеха
• какие навыки тебе нужны

Какие инструменты мы можем использовать для создания предметно-ориентированных языков?

Существуют разные способы создания DSL. Цель здесь состоит в том, чтобы создать язык с помощью инструментальной поддержки, сохраняя при этом разумные усилия. Мы не создаем следующую Java или C #, поэтому мы не собираемся тратить десятки человеко-лет на создание очень сложного компилятора или IDE с множеством функций. Мы собираемся создать полезный язык с хорошей инструментальной поддержкой и инвестициями, которые могут быть вложены небольшой компанией.

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

Подходы разделены на три группы, в зависимости от типа DSL, которые вы хотите создать:

• текстовые языки
• графические языки
• проекционные редакторы

Вы, вероятно, знаете, что такое текстовые и графические языки, но, возможно, вы раньше не сталкивались с проекционными редакторами. Это довольно интересные вещи, поэтому вам стоит взглянуть.

Текстовые языки

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

Прагматичный подход «сделай сам»

Сверните свое собственное решение: вы можете повторно использовать генератор синтаксического анализатора, такой как ANTLR (или Lex & Yacc, если вы парень старого стиля), и написать остальную часть обработки самостоятельно. Это выполнимо, но требует знания того, что вы делаете. Если вы не знаете, с чего начать, вы можете взглянуть на мою книгу по языкам построения .

Я уверен, что вы хотите прочитать это, поэтому я хочу сейчас слишком сильно его испортить, но путь более или менее такой:

1. Вы определяете грамматику лексера и синтаксического анализатора, используя ANTLR. Вы не знаете ANTLR? Нет проблем, вот хороший урок по ANTLR . В этом блоге есть много других статей о ANTLR .
2. Вы преобразуете дерево разбора, созданное ANTLR, в формат, с которым легче работать. Таким образом, вы получаете модель вашего кода.
3. Вы разрешаете ссылки, строите валидацию и внедряете систему типов как набор операций над моделью вашего кода. Это звучит сложно, но если вы знаете, что делаете, вы можете сделать это в несколько сотен строк кода.
4. Наконец, вы либо интерпретируете, либо компилируете модель своего кода
5. Вы создаете простой редактор для вашего языка. Чтобы узнать, как это сделать, обратитесь к учебникам в этом блоге или в книге. Я склонен использовать взломанный редактор, который создал сам. Я назвал это Канвас

Что мне нравится в этом подходе, так это то, что вы контролируете происходящее. Вы можете изменить всю систему, развить ее, и это достаточно просто, чтобы вы могли по-настоящему понять это. Конечно, при таком подходе вы не получите супер сложную IDE с десятками операций рефакторинга. Или вы не получите эти вещи бесплатно, по крайней мере.

XText

Xtext — это надежное решение для создания текстовых языков. На практике вы определяете свою грамматику способом, аналогичным тому, что вы делаете с ANTLR, но вместо простого парсера вы получаете хороший редактор. Этот редактор по умолчанию является плагином Eclipse. Это означает, что вы сможете редактировать файлы, записанные в вашем DSL в Eclipse. Если вы знаете, как работает платформа Eclipse, вы можете создать приложение RCP: т.е. урезанную версию Eclipse, в основном поддерживающую только ваш язык и удаляющую кучу вещей, которые не будут полезны для ваших пользователей.

Итак, Xtext предоставит вам редактор и парсер. Этот парсер создает для вас модель вашего кода с использованием Eclipse Modeling Framework (EMF). Так что это в основном означает, что вы должны изучить эту технологию. Я помню долгие дни чтения книги EMF как одного из самых скучных, ошеломляющих событий, которые я когда-либо испытывал. Я также помню, как задавал вопросы на форумах Eclipse и не получал никакого ответа. У меня есть открытые отчеты об ошибках, и я получил ответы три года спустя (я не шучу). Поначалу это приводило в уныние, но со временем сообщество, похоже, значительно улучшилось.Прямо сейчас материал, доступный на веб-сайте Xtext, несравнимо лучше, чем был раньше, и книга Лоренцо Беттини очень помогла (подробнее об этом позже).

Редакторы, сгенерированные Xtext, могут быть глубоко настроены, если вы знаете, что делаете. Вы можете избежать незначительных изменений с разумными усилиями, но если вы хотите делать более сложные вещи, вам нужно изучить внутреннее устройство Eclipse, а это не прогулка в парке.

Недавно Xtext избежал «ловушки Eclipse», добавив возможность создания редакторов также для IntelliJ IDEA и … в Интернете! Когда я впервые узнал об этом, я был очень взволнован. Я, как и многие другие разработчики, перешел на IntelliJ несколько лет назад, и мне не хватало способа легко создавать редакторы для IntelliJ IDEA. Так что это была отличная новость, даже если Xtext был создан для работы с Eclipse, поэтому поддержка IntelliJ IDEA не такая зрелая и проверенная в бою, как поддержка Eclipse. Я еще не пробовал веб-редактор, но из того, что я понял, он генерирует приложение на стороне сервера, которое в основном представляет собой Eclipse без головы, а на стороне клиента — три разных редактора на основе трех технологий (каждый с разным уровнем полноты). , Один полностью поддерживается Орионпроект Eclipse. В то время как другие два хорошо известны CodeMirror и ACE .

Вы можете проверить этот список проектов, реализованных с помощью Xtext, чтобы получить представление о том, чего можно достичь с помощью Xtext.

Текстовые языки: другие инструменты

Если бы мне приходилось создавать текстовый язык в большинстве случаев, я бы выбрал один из двух подходов, определенных ранее: мой подход «сделай сам» или использование Xtext. Тем не менее, есть альтернативы, на которые, я думаю, имеет смысл следить.

textX — это среда Python, вдохновленная Xtext. Вы можете определить грамматику вашего языка с синтаксисом, очень, очень похожим на тот, который используется в Xtext. textX не использует EMF и не генерирует код, но вместо этого использует силу метапрограммирования Python для определения классов в памяти. Несмотря на то, что textX кажется приятным и простым в использовании, textX не генерирует поддержку редактора, такую ​​как Xtext, так что это серьезная разница.

Если вы хотите лучше понять, как работает textX, посмотрите это видео.

Есть и другие инструменты, такие как Spoofax. Я не использовал это сам, поэтому я не могу ручаться за это. Это больше академический материал, чем языковой инструмент промышленного уровня, поэтому я хотел бы предложить немного осторожности.
Спуфакс можно использовать внутри Eclipse. Он основан на наборе DSL, которые можно использовать для создания других DSL.

Если вы хотите заглянуть в Spoofax, вы можете посмотреть на эту бесплатную короткую книгу от Eelco Visser под названием « Объявите ваш язык» .

Графические языки

Графические языки кажутся доступными, и часто специалисты в области чувствуют себя с ними легче, чем с текстовыми языками и их отвратительными синтаксисами. Графические языки требуют создания специальных редакторов, и они менее гибки, чем текстовые языки. Кроме того, они используются реже, чем текстовые языки, а инструменты для создания графических языков, как правило, менее зрелые и более неуклюжие. Здесь я представляю вам список из нескольких вариантов. Если вы хотите прочитать более полный список, вы можете посмотреть в этом обзоре о графических редакторах моделирования.

GMF, болезненное решение

Существует один способ создания графических редакторов для вашего языка, которые со временем приобрели довольно (не совсем положительную) репутацию. Его зовут GMF: Graphical Modeling Framework .
Да, вы можете использовать его для создания редакторов, которые можно использовать внутри Eclipse. Как и в Xtext, он основан на EMF. В основном вы используете EMF для определения структуры ваших данных, а затем GMF позволяет указать, как представлены различные элементы, как отображаются их соединения и тому подобное. Обычно вы редактируете детали каждого элемента на отдельной панели, что-то вроде формы.
Вы можете увидеть пример редактора GMF на картинке ниже.

Изображение с https://esalagea.wordpress.com/2011/04/13/lets-solve-once-for-all-the-gmf-copy-paste-problem-and-then-forget-about-it/

В настоящее время документации практически не существует, и заставить ее работать — задача, требующая большого терпения и решимости.

Эта структура имеет потенциал, и она мощная и гибкая, но работать с ней далеко не приятно.

Сириус, скрывающий ГМФ

Есть инструменты, построенные на основе GMF, чтобы сделать работу с языком менее сложной. Простым инструментом является Eclipse Eugenia , а более сложным — Eclipse Sirius .

Я использовал Eclipse Eugenia, и это помогло запустить мой редактор, но это ограниченный инструмент, и если вы хотите настроить свой редактор, вы возвращаетесь в GMF.

Я не использовал Eclipse Sirius сам, но, кажется, он неплохо поддерживается Obeo и используется в Thales, поэтому я ожидаю, что он будет иметь по крайней мере разумную зрелость и удобство использования.

MetaEdit +, коммерческое решение

MetaEdit + — это языковая рабочая среда для определения графических языков. В отличие от всех других инструментов, которые мы обсуждали, это коммерческий инструмент. Теперь, как правило, я предпочитаю основывать свои языки на решениях с открытым исходным кодом, потому что я нашел их более надежными Я знаю, что в худшем случае я всегда могу прыгнуть и самостоятельно управлять платформой, если мне действительно это нужно. С коммерческим решением вместо этого, что случится, если поставщик уйдет из бизнеса? Может быть, я смогу продолжать использовать инструмент, который купил некоторое время, пока он не будет совместим с операционной системой, которую я использую, и я не попаду в ловушку. Тем не менее, MetaCase (компания, стоящая за MetaEdit +) является солидной компанией, которая работает в этом бизнесе уже несколько лет.

Я дважды помогал с презентацией Юхи-Пекки Толванена, и оба раза меня впечатлили. У них есть зрелое решение, и они используют его для создания множества интересных DSL для своих клиентов. Мне очень нравится проверять их регулярные твиты на DSL недели . Вот несколько примеров:

Поэтому, если вам когда-нибудь понадобится графический язык, я бы посоветовал рассмотреть это решение. Альтернатива, на мой взгляд, заключается в использовании полноценного редактора проекций, который позволяет создавать и графические языки, но не только те. Любопытно? Продолжай читать.

Проекционные редакторы

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

Проекционный редактор — это редактор, который показывает проекцию содержимого, хранящегося в файле. Пользователь взаимодействует с такой проекцией, и редактор переводит эти взаимодействия в изменения в постоянной модели. Когда вы используете текстовый редактор, вы видите символы, вы добавляете или удаляете символы, и символы фактически сохраняются на диске. В проекционном редакторе вы можете редактировать таблицы, диаграммы и даже то, что выглядит как текст, но эти изменения будут сохранены в каком-то формате, отличном от того, что вы видите на экране. Может быть, в каком-то формате XML, может быть, в двоичном формате. Дело в том, что вы можете работать с этими файлами только внутри их специального редактора. Если вы подумаете об этом, это относится и ко всем графическим языкам: вы видите красивые картинки, перетаскиваете их, соединяете линии и, в конце концов, редактор сохраняет неясный формат,не красивые картинки, которые вы видите на экране. Суть проекционных редакторов в том, что они гораздо более гибкие, чем ваш типичный графический язык. Вы можете комбинировать различные обозначения и поддерживать все виды представлений, которые вам нужны для вашего случая.

Смущенный? Как ожидается, посмотрите видео ниже, посмотрите еще много видео, и через некоторое время все станет ясно.

Вы также можете взглянуть на это объяснение проекционного редактирования, написанное Мартином Фаулером.

Jetbrains MPS

Jetbrains MPS — это инструмент, которым я пользуюсь в течение нескольких лет, работая над ним ежедневно в течение последних 12 месяцев. Это чрезвычайно мощный инструмент, и это самый зрелый проекционный редактор из всех доступных. Это не случайно: Jetbrains инвестировала значительные средства в его разработку более десяти лет.

Хотите посмотреть, как это выглядит? Смотреть видео.

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

Теперь это означает, что вы должны быть готовы принять Jetbrains MPS и потратить значительное количество времени, чтобы правильно его изучить (или нанять кого-то вроде меня). Однако, если вы готовы сделать инвестиции, это может просто революционизировать ваши процессы.

Преднамеренная платформа

Это таинственный и интригующий.

Чарльз Симони — человек, который создал Excel, один из первых космических туристов и один из самых богатых людей на земле. В 1995 году он написал революционную статью «Смерть компьютерных языков, рождение преднамеренного программирования» . В этой статье он представляет новый, более интуитивный способ программирования, основанный на проекционных редакторах. Он начинает работать в Microsoft над этими идеями, но в 2002 году он оставляет Microsost, чтобы основать Intentional Software. С тех пор общедоступная информация об их инструменте, Преднамеренная платформа была крайне скудной. Они опубликовали несколько статей и сделали несколько презентаций.

Я слышал от людей, которые использовали его, что он имеет большой потенциал, но его еще нет. Конечно, я бы с удовольствием положил на это руки. Самое близкое, что вы можете получить, это прочитать этот какой- то старый обзор Интенциональной платформы от Мартина Фаулера. Возможно, однажды даже у нас, смертных, появится возможность узнать больше об этом легендарном инструменте.

Насколько я знаю, они работают с отдельными компаниями, но пока их инструмент не доступен для общественности.

Вся платформа

Это хороший Language Workbench, который слишком часто упускают из виду. Хотя в течение многих лет он использовался в производстве в крупной итальянской компании, его не хватает в части документации и маркетинга. Да, я знаю, что грустно, что просто инженерного превосходства недостаточно, чтобы завоевать популярность. В любом случае, если вы хотите узнать больше об этом, вы можете прочитать мой пост о начале работы со всей платформой .

Есть несколько концепций, которые я нахожу довольно интересными. Я не эксперт по всей платформе: я только что поиграл с ней и поговорил с его авторами.

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

Ниже приведен пример грамматики для разбора JSON, но тот же подход был использован для разбора очень сложных форматов, используемых в банковской сфере.

Еще одна идея, которая мне нравится в Whole Platform, это Pattern Pattern: возможность взять модель (в этом смысле фрагмент кода Java — это модель) и определить точки изменчивости, которые могут быть заполнены значениями из другой модели.

Кроме того, вся платформа довольно богата и поддерживает графические языки.

Риккардо Сольми и Энрико Персиани — умы всей платформы, и вам, вероятно, следует поговорить с ними, если вы заинтересованы в использовании этого языкового инструмента.
Изображения использованной мною Plargorm выпущены без лицензии CC Attribution 2.0 (https://creativecommons.org/licenses/by/2.0/)

Сравнивая разные подходы

ПОДХОД	ТИП	КОГДА ИСПОЛЬЗОВАТЬ ЭТО
Сделай это сам	текстуальный	Вы должны полностью контролировать поддерживаемые платформы, и вы не хотите никакой привязки к поставщику
XText	текстуальный	Вы хотите текстовый язык с хорошими редакторами, и вы хотите его быстро
textX	текстуальный	Вам нравится гибкость динамических языков, а поддержка редактора не важна для вас
Spoofax	текстуальный	Вам нравится работать с обоснованным теоретическим подходом, и вы не боитесь нескольких неровностей на дороге
GMF	графический	Вам нужна чрезвычайная гибкость, чтобы создать свой собственный графический редактор
Затмение Сириус	графический	Вы готовы обменять некоторую гибкость, чтобы сделать вещи быстрее и сохранить душевное равновесие
MetaEdit +	графический	Вы хорошо используете коммерческое программное обеспечение для компонента, страдающего отягощениями, и хотите быстро получить результат
Jetbrains MPS	проекционные	Вы хотите создать семейство языков с мощными и сложными инструментами, такими как симуляторы, отладчики, поддержка тестирования и многое другое
Преднамеренный верстак	проекционные	У вас есть связь, которая дает вам доступ к большинству таинственных и раскрученных языков Workbench
Вся платформа	проекционные	Вы хотите поддерживать существующие форматы и плавно перейти на новый подход

Я хотел бы подчеркнуть одну вещь: проекционное редактирование — это расширенный набор графического редактирования. Таким образом, вы можете определять графические языки, используя Jetbrains MPS. Поскольку не существует четкой и отличной альтернативы для создания только графических DSL, я бы использовал Jetbrains MPS в этом случае. В качестве альтернативы я мог бы рассмотреть вопрос о создании инструментария, ориентированного на Интернет. Другим интересным вариантом может быть просмотр чего-то вроде FXDiagram .

Все еще недостаточно?

Если вы хотите следить за появлением новых языковых рабочих мест, я предлагаю вам принять участие в «Language Workbench Challenge», семинаре, который обычно проводится в рамках конференции Software Language Engineering. Я соавтор статьи и присутствовал на последнем выпуске, и это было потрясающе.

Что мне нужно для успеха моего DSL?

Есть только две вещи, которые будут казаться очевидными, но это не так:

1. Вам нужны ваши пользователи, чтобы использовать его
2. Вам нужны ваши пользователи, чтобы получить выгоду от его использования

Чтобы достичь этого, вам нужно будет создать правильный инструмент поддержки и принять правильные навыки. Мы собираемся обсудить все это в этом разделе.

Заставьте пользователей использовать это

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

Если вы ориентируете DSL на разработчиков, они могут сопротивляться, потому что чувствуют, что не контролируют ситуацию, как при использовании языка общего назначения (GPL). Они также могут опасаться, что DSL понижает планку, проще в использовании, чем, скажем, Java. В дополнение к этому, как и все инновации, новый DSL угрожает опытным разработчикам, потому что он снижает важность некоторых из их навыков, таких как обширный опыт работы с особенностями текущего GPL, который вы используете в своей компании.

Если ваш DSL предназначен для не-разработчиков, как правило, легче заручиться их поддержкой. Почему?Потому что вы даете им сверхдержаву: способность что-то делать самостоятельно . Они могут использовать DSL для автоматизации процедуры, которая ранее выполнялась вручную. Возможно, до того, как DSL был доступен, единственная возможность для них что-то сделать — это побеспокоить какого-то разработчика написать собственный код. Теперь они получают DSL, что означает большую мощность и независимость благодаря этому. Тем не менее они могут сопротивляться принятию этого, если они воспринимают это как слишком сложное или если они чувствуют, что это не соответствует их мышлению.

Для меня ключ к дизайнеру DSL в этом случае — быть скромным и слушать . Слушайте разработчиков, работайте над тем, чтобы захватить их опыт и внедрить его в дизайн DSL или инструментария вокруг него. Вовлеките их в дизайн DSL. Общаясь с вашими пользователями, техническими или нет, сообщайте, что DSL станет для них инструментом, предназначенным для их поддержки и основанным на их понимании предметной области. При разработке DSL ковбойский подход не работает, вы должны преуспеть как команда или не преуспеть вообще.

Дайте преимущества пользователям

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

Мы обсудили важность DSL как средства коммуникации, как средства поддержки совместного проектирования. Это жизненно важно.

В дополнение к этому вы можете значительно повысить производительность своих пользователей, создав первоклассную поддержку инструментов.

Несколько примеров:

• отличный редактор с подсветкой синтаксиса и автозавершением: так что изучение языка и его использование чувствуется как бриз
• большие сообщения об ошибках: DSL — язык высокого уровня, и ошибка может быть очень значимой для пользователей
• симуляторы: ничто не помогает пользователям, так как возможность взаимодействовать с симулятором и видеть результаты того, что они пишут
• статический анализ: в некоторых случаях возможность проанализировать код и убедиться в возможной ошибке — большая победа

Это несколько идей, но можно принять и другие, в зависимости от конкретного случая. Поддержка определенных инструментов для определенных языков.

Поддержка инструментов: почему мы не заботимся о внутренних доменных языках

Есть один фактор, который часто упускается из виду, и это поддержка инструментов.

Многие практикующие считают, что единственная важная вещь — это синтаксис вашего языка или то, что он позволяет выразить, а все остальное — деталь.

Это в корне неверно, поскольку поддержка инструмента может экспоненциально увеличить производительность при использовании любого языка, особенно DSL. Это важный аспект для рассмотрения, потому что язык должен быть разработан с учетом поддержки инструментов.

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

Я записал это короткое видео на эту тему.

Создание языка: инструментальная поддержка от на Vimeo .

Поддержка инструментов является причиной, по которой языки, специфичные для внутреннего домена (например, поддельные DSL), не имеют значения: они не имеют какой-либо значительной поддержки инструментов.

При использовании некоторых языков хоста вы можете согнуть их достаточно, чтобы почувствовать какое-то чувство, что у вас есть собственный маленький язык, но это так. Есть некоторые языки, которые достаточно гибки, чтобы дать что-то приличное … как рубин. С другими языками вы получите очень плохие результаты. Мне жаль людей, пытающихся создать «внутренние DSL» для таких языков, как Scala или Java. Худшее из всех — это Лисперс. Я понимаю их философию «если вы хотите решить проблему в LISP, сначала создайте свой диалект LISP, а затем решите его, используя его». Я понимаю и считаю, что это отличная техника. Просто давайте не будем притворяться, что это настоящий DSL. Это не то, чем вы можете поделиться и работать с экспертами в предметной области. Это может быть вашей уловкой, чтобы быть более продуктивным, но это все.

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

• жалко его и его пользователей
• ярость за путаницу, которую он создает. Настоящие DSL очень разные, и они могут принести реальные выгоды. Хватит смешивать их с этой … штукой

Просто создайте настоящий DSL, поэтому внешний DSL!

Какие навыки необходимы для написания DSL?

Как правило, вам необходимо обладать высокими навыками абстракции , которые обычно необходимы для метапрограммирования. Если написание библиотеки в 3 раза сложнее, чем написание программы, написание каркаса или DSL обычно в 3 раза сложнее, чем написание библиотеки.

Вам нужно быть скромным : вам может понадобиться разработчик, но обычно вам нужно создать этот DSL для других специалистов, которые собираются использовать его для своей работы. Послушайте, что они делают, поймите, как они работают. То, что может показаться вам неправильным или наивным, может иметь причины, которые вы еще не понимаете. Выступать в роли всесильного эксперта — это единственный лучший способ создать отказавший DSL, который на практике бесполезен и поэтому не используется.

Помимо этого, практикуйтесь и учитесь. Продолжая делать это в течение нескольких лет, нужно добиться цели.

Ресурсы

Теперь, когда вы увидели, что могут принести вам DSL, и у вас есть идея, как их создавать, вы должны быть счастливы.

Но это не так, вы хотите больше, вы хотите лучше понимать DSL, вы хотите узнать о них все.

Ну, я не знаю обо всем, но определенно могу дать вам несколько советов. Я могу сказать вам, где найти хорошие вещи.

Давайте посмотрим, что мы можем найти:

книги

веб-сайты и документы

компании

книги

Я хотел бы начать предлагая прочитать DSL Engineering по Markus Вольтера . Эта PDF-версия книги предназначена для пожертвований. Так что просто прочитайте это и пожертвуйте. В качестве альтернативы вы можете найти печатную версию на Amazon.

Книга начинается с вводной части: очень полезно прояснить вашу терминологию. После этого начинается проектирование DSL, в котором особое внимание уделяется различным аспектам. Если у вас нет прямого доступа к специалисту, который научил бы вас создавать DSL, чтение этой части этой книги — лучшая альтернатива, которую я могу порекомендовать (вместе с практикой, конечно, насколько это возможно).

Затем следует часть о реализации: помните, что у Маркуса есть докторская степень, но он, в первую очередь, тот, кто выполняет свои задачи, поэтому эта часть очень хорошо написана, с примерами, основанными на Xtext, Spoofax и MPS.

Часть IV о сценариях, в которых полезны DSL. Учитывая, что это основано на его большом опыте в этой области, есть много интересных комментариев.

У меня была возможность поработать с Маркусом. Раньше я восхищался им до встречи, а теперь я восхищаюсь им еще больше. Он просто лучший в этой области, поэтому, если вы можете чему-то научиться у него, сделайте это. Читайте его книги, смотрите его презентации, следите за его проектами. Это будет хороший способ потратить ваше время. В последнее время он работает над JetBins MPS, так что вы должны следить за тем, что происходит с mbeddr и IETS3 . Mbeddr — это и набор плагинов для MPS, и реализация языка C в MPS со специальными доменными расширениями для поддержки разработки встроенного программного обеспечения. IETS3 — это язык выражения, встроенный в MPS.

Мартин Фаулер — очень известный мыслительный лидер и автор бестселлеров. Я действительно восхищаюсь его ясностью. Он является автором предметно-ориентированных языков , книги о внутренних и внешних DSL.
Я нахожу ментальные модели, представленные в книге, весьма полезными и элегантными. Однако на практике я считаю, что внутренние DSL не имеют значения, поэтому меня интересуют только некоторые части этой книги.

Существует 15 глав, посвященных языкам, специфичным для внешнего домена. Хотя эти главы организованы вокруг методов реализации, есть комментарии и замечания, из которых вы можете узнать некоторые принципы проектирования.

Я думаю, что разделы об альтернативных вычислительных моделях и генерации кода очень ценны. Вам будет трудно найти исследование этих тем на этом уровне детализации где-либо еще.

Книге 7 лет, и методы, возможно, развивались с момента ее написания, но подавляющее большинство представленных в книге соображений по-прежнему актуальны. И, конечно, они продуманны и хорошо объяснены, как и следовало ожидать от Мартина Фаулера.

Если вы интересуетесь текстовыми языками и, в частности, ANTLR, вам обязательно стоит взглянуть на шаблоны языковых реализаций от Terence Parr. Мне нравится автор, мне нравится издатель (Прагматическая Книжная полка), и неудивительно, что я люблю книгу.

Книга начинает обсуждать различные алгоритмы разбора. Если вы хотите узнать, как все работает, вы должны взглянуть на эти главы. Затем есть главы о работе с абстрактным синтаксическим деревом, извлечении информации, ее преобразовании. Это тот материал, который вам нужно выучить, если вы хотите стать языковым инженером. Также есть главы по разрешению ссылок, созданию таблиц символов или реализации системы типов. Это основы для изучения того, как обрабатывать информацию, выраженную в вашем DSL.

Наконец, Теренс объясняет вам, как использовать информацию, которую вы обработали, создавая интерпретатор или генератор кода. На этом вы заканчиваете свое путешествие, увидев, как создать полезный язык от начала до конца. Эта книга даст вам прочную основу, чтобы научиться внедрять DSL. Единственное, чего не хватает, это обсуждения того, как проектировать DSL, но это не является целью этой книги.

Если вы смотрите на MPS, то вокруг не так много ресурсов. Возможно, имеет смысл купить две книги у Фабьена Кампаня на MPS Language Workbench . Они подробно объясняют все многие особенности MPS (правда, некоторые из них немного неясны). Если бы мне пришлось найти одну вещь, отсутствующую — это больше советов по языковому дизайну. Эти книги являются очень хорошими справочными материалами, чтобы узнать, как работает MPS, но не так много советов о том, как объединить эти функции, чтобы получить ваши результаты. Одна из причин этого заключается в том, что MPS является чрезвычайно мощным инструментом, который можно использовать по-разному, поэтому нелегко давать общие указания.

Том I отдельно объясняет различные аспекты языка: как определить структуру (метамодель), как определить редакторы, поведение, ограничения, правила системы типов и так далее. Большинство глав написано в виде справочника (например, глава «Структура AspectStructure на практике» ). Все, что вам нужно изучить, чтобы начать работу и создавать настоящие языки с помощью MPS, объясняется в томе I.

Том II в основном о продвинутых вещах, которые вы можете смело игнорировать в начале. Я предлагаю изучать эту книгу только тогда, когда вы чувствуете себя комфортно со всеми темами, описанными в первом томе. Если вы никогда раньше не использовали MPS, это займет некоторое время. Во втором томе объясняется, как использовать структуру сборки для определения сложных конфигураций здания, и дается обзор всех видов тестирования, которые вы можете использовать для своих языков. В нем также показано, как определить пользовательские аспекты для вашего языка или пользовательского постоянства.

Я купил версию Google Play, но они доступны также в печатной форме.

На Xtext есть довольно практичная и приятная книга от Лоренцо Беттини: Реализация доменных языков с Xtext и Xtend . Я написал рецензию на второе издание этой книги: если вы хотите прочитать мое подробное мнение об этой книге, вы можете перейти по ссылке.

Если вы хотите научиться писать текстовые языки с хорошей поддержкой инструментов, вы можете начать с нескольких учебников по Xtext, а затем перейти к этой книге. Эта книга объяснит вам все, что вам нужно знать, чтобы использовать Xtext для создания довольно сложных редакторов для вашего языка. Единственное предостережение в том, что Xtext является частью сложного экосистемы, поэтому, если вы действительно хотите стать экспертом по Xtext, вам необходимо изучить EMF и Xtend. Книга хорошо научит вас тому, что вам нужно знать, чтобы начать изучать эти предметы, но вам, возможно, придется завершить свое обучение и с другими ресурсами, если вы хотите прогрессировать.

Что мне нравится в этой книге, так это то, что она не является справочным руководством, но она содержит указания и мнения по таким темам, как Скоупинг или построение правил системы типов (автор имеет некоторый значительный опыт в этой конкретной теме). Кроме того, автора интересуют лучшие практики, поэтому вы ознакомитесь с его результатами тестирования и непрерывной интеграции. Такие вещи вы не должны игнорировать, если вы серьезно относитесь к языковой инженерии.

Если вы заинтересованы в DSL в целом, вы можете взглянуть на DSL в действии . Книга интересная, но у меня есть два комментария:

1. Слишком много внимания уделяется внутренним DSL, которые, как мы все знаем, не являются реальными
2. Они неправильно написали мое имя. -1 очко за это

В частности, о внешних DSL не так много: автор кратко обсуждает Xtext, а затем проводит главу об использовании комбинаторов анализатора Scala для создания внешних DSL. Это не было бы моим первым выбором. Так что если вы заинтересованы в изучении того, как реализовать внешний DSL, не выбирайте эту книгу. Тем не менее, если вам нужно подробное введение в тему DSL, если вы дегенерат, предпочитающий внутренние DSL, а не внешние DSL, или если вы хотите прочитать все доступные ресурсы на DSL, эта книга будет хорошим выбором.

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

Что из этой книги вы должны получить, так это важность захвата Домена во всех ваших программных артефактах. В книге подчеркивается важность создания общего языка, который будет использоваться заинтересованными сторонами. Это полностью и абсолютно актуально, если вы хотите создавать доменные языки. Что не является частью этой книги, так это то, как отобразить эту модель предметной области на язык. Для этой части вы должны обратиться к другим книгам, относящимся к дизайну DSL. Эта книга является хорошим дополнением к любому из них.

Сайты и документы

• models-languages.com : блог от Джорди Кэбота о моделировании в целом. Многие темы представляют интерес для практиков DSL. Я бы посоветовал следить за новостями в области языковой инженерии.
• Разработка DSL: 7 рекомендаций по проектированию предметно-ориентированного языка на основе доменно-управляемого дизайна : краткий список предложений по проектированию DSL. Хотя он был опубликован несколько лет назад, я думаю, что он все еще актуален. Эта статья была написана Йоханом ден Хааном, техническим директором Mendix. Mendix — это компания, работающая в области модельного бизнеса.
• Xtext Screencasts: коллекция скринкастов о Xtext. Это не совсем недавно, но все еще очень ценно
• Рекомендации по проектированию для языков, специфичных для предметной области : 26 рекомендаций, кратко изложенных в короткой статье. Рекомендации построены вокруг языковой цели, языковой реализации, языкового содержания, абстрактного синтаксиса и конкретного синтаксиса.
• Когда и как разрабатывать предметно-ориентированные языки : статья объемом более 30 страниц с интересной библиографией из почти 100 статей. В документе представлено несколько шаблонов, которые будут использоваться при разработке языков, и приведен список открытых проблем.
• WebDSL: тематическое исследование в предметно-ориентированной языковой инженерии : очень подробное практическое исследование очень практичного DSL. Автором статьи является Eelco Visser, который очень хорошо известен в этой области.

Компании

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

Первое, очевидное имя — Itemis. Это немецкая компания с небольшими офисами во Франции и Швейцарии. В них работают одни из лучших в этой области: я встречался и работал с Маркусом Фельтером и Берндом Колбом, и меня очень впечатлил уровень, на котором они работают. Они работали со многими компаниями и реализовали так много проектов, что список будет слишком длинным. Я бы просто сказал, что в последующие годы они проделали потрясающую работу, используя Jetbrains MPS. Они создали проект mbeddr и из него получили набор утилит, названных платформой mbeddr, которые внесли огромный вклад в рост MPS. Они внесли значительный вклад в сообщество Language Workbench, поэтому, если вам нужна помощь по DSL, вам следует серьезно подумать о работе с ними.

TypeFox — еще одна немецкая компания. Я взял интервью у одного из основателей некоторое время назад. В компании задействовано несколько основных коммиттеров Xtext, так что вы можете себе представить, что у них есть серьезные знания в Xtext и платформе EMF в целом. Если вам нужно обучение Xtext или консультации, я бы посчитал их лучшим выбором. Они также являются членами Eclipse, и я ожидаю, что они смогут создавать сложные решения на основе Eclipse. Если вы хотите услышать больше, вы можете прочитать это интервью с Яном Конлейном . Ян является одним из основателей компании, и мы поговорили через несколько месяцев после создания компании.

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

В настоящее время я не думаю, что они предлагают консалтинг MPS (для этого вы можете поговорить со мной или с Itemis).

Выводы

Есть много причин, по которым вам стоит задуматься о предметно-ориентированных языках. Я видел, как компании получают огромную выгоду от DSL. Большинство людей, с которыми я работал, использовали DSL в качестве ключевого дифференциатора, который помог им повысить производительность в 10-20 раз, сократить время выхода на рынок и циклы обратной связи, увеличить долговечность их бизнес-логики и многое другое.

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

Не могли бы вы мне помочь, пожалуйста?

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

Огромное спасибо!

Несколько идей:

• Поделитесь этим в Твиттере
• Поделитесь этим на Facebook
• Поделитесь этим на LinkedIN
• Поделитесь этим в Google+
• Напишите об этом в своем блоге
• Отправить электронное письмо своим коллегам

Ссылка:

Полное руководство по (внешним) предметно-ориентированным языкам от нашего партнера по JCG блоге .