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

Конечно, в основе инструментария проекционного языка лежит то, что реализация языков устраняет одно критическое препятствие - написание грамматики для вашего языка, которая соответствует технологии синтаксического анализа du jour - и позволяет вам придать вашему языку вид В то же время хорошо, но MPS действительно справляется с этим.

Это заставило меня немного задуматься о направленности области языковой инженерии. Мне кажется, что мы, языковые инженеры, очень много говорим о том, как наши инструменты работают или должны работать. Вы даже можете назвать это метаязыковой инженерией: вместо (в первую очередь) создания реальных языков для реальных пользователей мы (в первую очередь) создаем инструменты для создания языков - по крайней мере, иногда мы, кажется, предпочитаем что. Это похоже на то, что обычные Java-разработчики часто делают запросы на включение в репозиторий OpenJDK.

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

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

Я хочу сказать, что здесь нужно найти баланс, и я думаю, что наша профессиональная ниша часто ошибается на стороне меты. Я сам полностью виноват в этом - см. Также мое вскрытие на моем родном языковом верстаке, Мас. Я также знаю множество коллег-языковых инженеров, которые в какой-то момент своей карьеры, по-видимому, подумали что-то вроде Fsck‹ существующий инструмент ›, я создам свой собственный, который намного круче!, И фактически приступили к созданию своего собственный языковой инструмент, поэтому я не могу быть статистической аномалией в этом.

Инструменты на арене языковой инженерии за последние годы значительно улучшились: MPS и Xtext стабильно развиваются, Scala и Haskell отлично подходят для внутренних DSL, а годы lex и yacc тоже давно прошли. Неужели все существующие инструменты постоянно не подходят для любого конкретного проекта?

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

Фактически, я стал думать о DSL как о «не более чем» данные + инструменты. Несмотря на то, что языковая инженерия часто имеет свои собственные специфические проблемы, нет причин, по которым нам абсолютно, на 100% требуется языковая рабочая среда для создания языков. Конечно, языковая рабочая среда позволяет вам добраться до нее намного быстрее, но это также означает, что использование, казалось бы, несовершенной языковой среды все же намного лучше, чем взять творческий отпуск, чтобы сначала создать эту идеальную языковую рабочую среду (как будто! ...) вместо создание языка, которым вы действительно можете сделать людей счастливыми.

Если за этой тирадой скрывается призыв к действию, я думаю, это может быть следующее: найдите хороший домен (возможно, даже «деловой», т.е. нетехнический), создайте для него хороший DSL, убедитесь, что это легко для работы (простая установка и / или в виде пакета в виде веб-или даже мобильного приложения), и что с ним легко интегрироваться и расширяться, и посмотреть, кого вы можете сделать счастливым.