Language Oriented Programming (LOP) в действии

  • Tutorial


В продолжении предыдущей публикации по теме Domain Driven Design, где Николай Гребнёв последовательно свёл тему проектирования при помощи DDD к необходимости использования языка предметной области, — в данной публикации будет обсуждаться практика проектирования и разработки как самих языков, так и программирование на них (опыт компании JetBrains).

Доклад smax Максима Мазина с прошлогодней конференции архитекторов ПО Application Developers Days

Видео доклада:




Скачать

ftp.linux.kiev.ua/pub/conference/peers/addconf/2011/1a1-language-oriented-programming-mazin.avs.avi

Презентация




docs.google.com/present/view?id=dccwwvbq_729dxjj82gc

Текстовка доклада (выполнена Belonesox)




Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Сегодня у меня первый доклад, рассказывать я будут про языковую тему в программировании.
Меня зовут Максим Мазин, я работаю в компании JetBrains инженером в проекте YouTrack.
YouTrack — это багтрекер, и самое увлекательное в YouTrack то, что он написан с помощью Language Record программирования.
Что это такое? Это такая концепция, которая полагает, что при написании программ, первым делом вы создаете специальный предметно-ориентированный язык, а затем, на этом предметно-ориентированном языке, вы начинаете уже писать собственно код программы.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Для чего это? Какой от этого прок, и что мешает делать так всем — об этом я и буду сегодня рассказывать.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Смотрите — вот существуют универсальные языки программирования. При программировании при помощи языка Java, PHP или C# возникает проблема — у вас при программировании возникает огромное количество boilerplate-кода, т.е. такого кода, который будет повторяться из раза в раз, но не потому, что он делает какую-то содержательную работу, а просто для того, чтобы компилятор мог этот код скомпилировать.
Писать скобочки круглые, точки, … ну и так далее.
В случае, когда вы пользуетесь каким-то фреймворком, то у вас появляется еще дополнительная боль от фреймворка.
Вам нужно инициализировать библиотеки, открывать окна, устанавливать какие-то свойства, в зависимости от того, что у вас за библиотека.
В принципе, во многих современных языках программирования, ну например, С#, существует практика добавлять в язык предметно-ориентированные конструкции.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
В языке Java существует конструкция synchronized, которая не является какой-то конструкцией общего назначения, является специальной, предметно-ориентированной конструкцией, предназначенной для параллельного программирования.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Точно так же, в языке C++, существует перегрузка операторов. Вот, сравните.
В нормальной ситуации, если бы у вас не было конструкции synchronized вам бы пришлось написать вот столько вот кода.
Блок «finally» и блок получения блокировки, это все вот boilerplate код, который не интересно писать постоянно.
Вместо этого существует DSL-ная конструкция «synchronized», которая позволяет захватить блокировку и не беспокоится о том, что ее надо отпустить.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Точно также в языке C++ есть механизм перегрузки операторов, который позволяет вам сделать вид, как будто у вас определены специальные операции, например, над комплексными числами.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Это все очень хорошо, но как вы знаете, что в языке Java, начиная с пятой версии, появились read-write локи, и это означает для нас, что нам снова нужно писать код вот такого стиля, как показано слева:
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Т.е. надо блокировки захватывать, блокировки отпускать, … это все полностью нивелирует удобства.
Если бы можно было писать… самостоятельно расширять языки, нам бы удалось решить разные проблемы.
Например, те конструкции, языковые расширения, которые есть, в языке Java, они позволяют вам решать определенный набор задач. Но мы в жизни сталкиваемся и с другими задачами. Например, если мы пишем веб-аппликейшн, то нам нужно работать с базами данных, писать веб-уровень, и так далее. Для этого DSLей нет, есть только фреймворк.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Точно также, если мы используем какую-нибудь концепцию вроде dependency injection, то нам тоже нужно для этого использовать фреймворки, и хуже того — использовать смеси языков, писать одновременно на Java, на XMLе, и все это не очень весело.
И главное — нам ничего с этим не поделать, потому что создание языкового расширения грозит нам разными рисками.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Какие проблемы возникают при создании DSL и почему бы при возникновении какой-нибудь потребности не бросаться сразу создавать DSL?
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Самая главная проблема, с которой все сталкиваются все люди, которые пытаются заниматься созданием DSLей, это совместимость языковых расширений.
Совместимость имеется в виду возможность использовать одновременно два языковых расширения, которые созданы независимыми разработчиками.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Вот например. Если у вас есть некоторые библиотеки и фреймворки, в нашем случае для Java, например
Hibernate, Spring или Joda Time, то все они между собой совместимы, принципиально, на уровне компиляции.
Т.е. вы можете одновременно использовать в вашем проекте компоненты и Hibernate и Spring, и ничего вам не может помешать.
Но если у вас есть языковые надстройки, в виде каких-то макросов, или еще каких-нибудь техник, которые добавляют вам предметно-ориентированные конструкции в язык Java, то и эти надстройки созданы независимым образом, то все время существует риск, что эти надстройки будут с друг другом конфликтовать.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Вот например, такой очень простой пример.
Допустим у нас откуда-то появилось расширение, которое делает что-то полезное, и в частности поддерживает интерполяцию выражений в строках.
Можно написать такую конструкцию, и вместо «resultCount» будет подставлено значение этого выражения.
В тоже самое время, в друг к нам приходит другое языковое расширение, которое позволяет делать что-то полезное и в частности тоже делает интерполяцию строк. В Java же нет интерполяции строк, поэтому достаточно ожидаемо, что разные люди будут ее релизовывать в разных языковых расширениях.
И допустим, синтаксис слегка отличается. Тогда при совместном использовании языковых расширений A и B, у вас мгновенно возникает неустранимая неоднозначность, как следует интерпретировать вот этот вот buzz.
Данный пример он очень простой, но по факту, все, кто создает DSL на основе текстовой информации, так или иначе сталкиваются с проблемой, у них возможно нет уверенности в том, что расширения не будут противоречивы.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Другая проблема, которая мешает нам создавать DSLи. Допустим тем не менее, вопреки сложностями и проблемам с совместимостью разных расширений вы принимаете решение написать DSL.
Пишите какой-нибудь препроцессор, натравливаете этот препроцессор на вашу программу
вашими DSLными конструкциями, она компилирует и выдает какой-то код, байт-код например,
или какой-то исполняемый код.
Это все очень хорошо, но в наше время никто не пишет код, не используя IDE.
Так не делают просто, потому что без использования IDE продуктивность разработчика драматически снижается.
Поэтому в большинстве случаев, когда вы создадите такой DSL, будут ситуации, когда ваши разработчики, ваши коллеги, предпочтут использовать просто язык Java в Idea, просто язык C# вместе с ReSharperом, нежели брать ваше поделие, и что-то с помощью вашего поделия писать, потому что нет поддержки IDE.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Под поддержкой IDE понимается все возможности, которые современные IDE оказывают разработчику. Т.е. это подсветка синтаксиса естественно, подсветка ошибок до компиляции, рефакторинг, интеграция с Version Control-ами, все остальное.
И да, можно отметить, что само по себе создание языка
это решенная математическая задача.
Если у вас есть пример для представления синтаксиса, вы сможете создать компилятор.
Но она, тем не менее, трудоемкая, даже если вы используете компилятор компиляторов.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
И если вы погружаетесь в языково-ориентированное программирование очень глубоко, т.е. вы начинаете строить разные расширения, то у вас проблема совместимости выходит на новый уровень. Т.е. у вас не только совместимость на уровне грамматики, но также например, на уровне системы типов.
Т.е. если у вас есть два независимых расширения, то нужно, чтобы системы типов этих двух расширений, нормально отрабатывали и нормально приводились друг к другу.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Существуют очень много разных попыток сделать это, поддержать DSL в том или ином виде, тема очень горячая, тут наверное еще можно добавить Nemerle, и может быть еще OCaml, сейчас есть очень много разных средств, чтобы создавать DSLи.
В рамках Eclipsa существует XText-фреймворк, который позволяет написать грамматику и получить что-то вроде DSLя c поддержкой IDE.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
У всех у них есть проблемы. Главная проблема вытекает из того, что они ориентированы на текстовые грамматики.
А раз они ориентированы на текстовые грамматики, то у них нет никаких шансов избежать проблемы совместимости конструкций.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Но к счастью, в нашей компании JetBrains, была создана среда MPS.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
MPS означает meta-programming system, в основном предназначена для создания и расширения языков, причем такого расширения, что сразу после его создания появлялась поддержка IDE.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Я уже много раз сказал, что текстовые грамматики неизбежно приводят к проблемам. Поэтому естественным решением является работа напрямую с AST → абстрактным синтаксическим деревом, и заставлять программиста прямо, напрямую создавать абстрактное синтаксическое дерево.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Попытки такие ранее предпринимались, и как правило такие попытки сводятся к редактированию диаграмм.
Рисуется диаграмма, в некотором смысле… у меня ребенок программирует на свойствах в большей степени, вы рисуете диаграммы, у вас получаются картинки, далее эти картинки собираются, получается код.
Есть проблема — рисовать эти картинки неудобно — мышкой хватать, таскать, неудобно.
У нас, у программистов, есть привычка писать код вручную.
Поэтому в MPSе реализована концепция проекционных редакторов.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
О чем речь? Вот у вас есть абстрактное синтаксическое дерево. Т.е. это то представление программы, которое получается, в любом случае получается, когда парсер распарсил программу.
В то же время, у вас есть его проекция, во что-то вроде текста.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Для каждого узла этого синтаксического дерева есть соответствующая ему ячейка.
Те из вас, кто знакомы с TeXом, должны примерно представлять, примерно похожие концепции.
Точно также, для каждого элемента у вас есть ячейка, ячейки объединяются в еще более крупные ячейки и так далее.
При этом воздействие на эти ячейки, когда вы пишете в эти ячейки, или каким-то образом на них воздействуете, то сразу же, мгновенно влияет на эту деревяшку.
При этом наша цель, как разработчиков MPS, сделать так, чтобы вы вообще не чувствовали, что вы работаете не с текстом, а с напрямую с деревяшкой. Здесь конечно проблема, но те из вас, кто пользуются IDEA, должны понимать, что когда вы редактируете текст в IDEA, Eclipse или еще где-то, вы тоже не редактируете текст — вы тайпаете что-то, что поглощается IDEA, и она это во что-то превращает.
В случае Eclipse это в большей степени редактирование текста, в случае IDEA — это еще меньше редактирования текста.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
У такого проекционного редактора есть положительные стороны, и есть отрицательные стороны.
Положительные стороны понятны. У нас нет никаких текстовых грамматик, никакого текста, никаких проблем текстовых грамматик, никаких конфликтов, все совместимо, все очень хорошо.
Отрицательная сторона, состоит в том, что все-таки есть некоторое отличие от редактирования текста. В тоже самое время, проблема. Дело в том, что привыкание… по нашему опыту, люди, которые начинают работать с MPSом, они привыкают к стилю программирования внутри MPSа, примерно в течении двух недель.
Т.е. в течении этих двух недель они могут выдавать какую-то положительную обратную связь, о том, что им неудобно, непривычно, чем-то отличается от программирования в текстовом редакторе.
Через две недели они привыкают и начинают работать с той же скоростью, как они работали ранее.
Я надеюсь, что если вы попробуете скачать, и начнете пользоваться, то мы получим больший feedback, и мы сможем сделать проекционный редактор еще более похожим на текстовый редактор.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Идея такая. При создании языков вы выписываете мета-модель языков, его абстрактный синтаксис, задаете систему типов, описываете конкретный синтаксис, и автоматически получаете на выходе язык, вместе с компилятором, плюс MPS-тест для работы с кодом на этом языке.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Внутри MPSа, вместе с MPSом поставляется ряд готовых расширений, поскольку мы проекты пишем в конце-концов на Java, т.е. мы все генерим в джаву, то у нас стек языков который есть предназначен в конце-концов для джавы.
Вместе с MPSом, внутри него, поставляются разные языковые расширения, для работы с замыканиями, с коллекциями… и так далее. И некоторое количество языков для работы с XML, тупо для работы. Т.е. вы можете вводить XML, и что самое главное — генерировать XML из своего кода.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Ну и еще есть некоторое количество языков, которые предназначены для создания языков.
MPS в плане создания языков вполне честно (??? 16:20)
Вместо демонстрации — выглядит как-то так ↑.
Я показывают не со своего компьютера, поэтому все, кого интересует демонстрация, приглашаю на стенд в коридоре.
Тут посмотрите, как просто взять и заDSLлить поддержку языковой конструкции.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Фактически, это все, что я хотел рассказать, осталось несколько важных вещей.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
MSP подходит не только для создания языковых расширений, т.е. не только в Java можно добавить конструкций, которых в них не хватает, но также вы можете создавать какие-то собственные DSLи.
Вот например, Мартин Фаулер создал язык для описания своей финансовой отчетности.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Кроме того, с помощью MPSа мы написали YouTrack, такой большой багтрекер — большой, в смысле с большим количеством кода (сгеренированного). Но мой предыдущий опыт разработки подсказывает мне, что код содержательный, который мы пишем и редактируем, этого кода достаточно мало.
Опять таки интересующимся, мы на выходе можем показать, как выглядит код в редакторе, сколько там таблиц.
Кода достаточно мало, из-за того, что уровень абстракции поднят достаточно высоко.
Для разработки YouTrack был создан набор языков, часть этих языков открыта, а часть — закрыта.
Мы их пока не отдаем, потому что они не достигли пока продажного качества.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
Вот, приложение настоящее, живое.
Language Oriented Programming (LOP) в действии (Максим Мазин, ADD-2011).pdf
У MPSа есть положительное свойство. Он «Apache 2.0»-лицензированный, абсолюно бесплатный, даже для коммерческого использования.

Скачать его можно здесь.
www.jetbrains.com/mps

Блог про MPS:
blogs.jetbrains.com/mps

Теперь если у вас есть какие-то вопросы, предлагаю вам их задать. (18:46)
Лаборатория тестирования
33,00
Компания
Поделиться публикацией

Похожие публикации

Комментарии 42

    +1
    Вопрос, который задаётся из года в год. Планируется ли поддержка C# хоть когда-нибудь?
      +4
      Вы имеете в виду, можно ли в MPS реализовать язык, аналогичный C#? Вообще, C# с DSL-ями — это Nemerle. Можно уже брать и юзать. Про него как раз вчера стенограмму постили.
        +3
        Про Nemerle — вот тут: habrahabr.ru/post/143221/
          0
          Вопрос скорее в том, планируется ли официальная реализация C#. Я знаю, что есть вариант от Robert Hencke, и продолжение от mezastel, хотя и не знаю, если честно, насколько они хороши.
          +1
          Зачем? Для тех же целей вы можете использовать Roslyn, не?
            0
            Можно, но насколько тесно можно интегрировать Roslyn в IDE? Насколько я знаю, сейчас это ограничивается лишь кодогенерацией перед билдом, и о поддержке конструкций вашего расширения в intellisence/debug-режиме речи не идёт.
              0
              Согласен. Но это общая проблема всех DSL.
                0
                MPS теоритически её решает, включая поддержку автодополнения, подсветки и отладки.
            +2
            Тут надо призвать собственно автора доклада → smax.
              0
              Боюсь, что нами поддержка C# не планируется. По большому счету мы добавляем языки по мере нашей собственной необходимости. То есть те языки, которые необходимы для написания баг-теркера YouTrack и других проектов JetBrains. Поэтому у нас есть поддержка для Java, Javascript, CSS, REST, etc. A для C# — нет.

              Хорошая новость состоит в том, что качественную поддержку остальных языков в MPS начали делать люди, не имеющие отношения к JetBrains. Например, компания Realaxy сделала IDE для ActionSctipt на базе MPS. А Markus Völter разрабатывает проект mbedder — Си IDE для встраиваемых систем.
              0
              Расскажите пожалуйста, когда решение задачи возможно только с применением DSL? Какие типы этих задач?
                +1
                Пожалуй, не — только, а вместо. Бизнес-приложение, с ясной моделью и изменчивыми требованиями. Вроде учет чего-то.
                  0
                  Нет таких задач. В конце концов все сводится к машинному- или байт-коду, так что все можно написать прямо на нем. :) Вопрос удобства программиста.
                    +1
                    вот интересный пример решения задачи:
                    codefest.ru/program/2012-03/the-practice-of-MPS/

                    ребята делали реализацию приложения на Java + макросы и затем, при помощи MPS автоматом конвертили полученный код в Object C, который компили уже на iOS
                    +1
                    Может кто разъяснит, что мешает реализовать модель предметной области (Model Driven Design — техническую часть DDD) средствами самого языка программирования, не прибегая к метапрограммированию?

                    Просто слишком уж резкий переход от Domain Driven Design (Model Driven Design) к необходимости разширения языка программирования при помощи препроцессинга.

                    Или DDD подразумевает использовать разширения языка программирования, тогда опять же непонятно зачем, в чем выгода?
                      +1
                      Для ясности, чтобы не отвлекаться на низкоуровневые конструкции, а писать на языке задачи.
                        0
                        Ясность — IMHO вопрос правильной реализации, можно и на вышеупомянутом MPS-е сделать непонятную кашу.
                        Хотелось бы увидеть результаты анализа, сравнения разных подходов.

                        А упомянутая конструкция synchronized выглядит не убедительно,
                        не знаю как на Java, но на C++ это решается средствами языка при помощи RAII.
                          0
                          В контексте DDD и DSL, лучше смотреть не на пример с synchronized, а на эту картинку:
                          image
                          Хоть и этот пример тоже не совсем показателен, но MPS, помимо расширения Java, предполагает в том числе и создание нового языка, собственного DSL, на котором описывать бизнес-правила модели. При этом сохраняется полная поддержка со стороны IDE.

                          Вместо того, чтобы оперировать концепциями ООП, вы могли бы оперировать терминами из Ubiquitous Language и это, теоритически, было бы правильнее.
                          0
                          Есть мнение, я его целиком не поддерживаю, но склоняюсь всё же к нему. Что если в языке необходимы макросы, то он недостаточно выразителен.
                          Немало число макросов (типа описанных тут synchronized и read) реализуются на банальных ФВП.
                          Даже async/await и call-cc можно реализовать без макросов.
                          0
                          Я так понимаю, что переход от DDD к DSL — это личное мнение Сергея Полаженко, который опубликовал стенограмму. Но логика тут есть, конечно. Если DDD говорит о том, что программа должна полностью повторять язык проблемной области, то DSL, полностью соответствующий проблемной области — это еще один шаг вперед к полному слиянию в экстазе. :)

                          Хотя я и не уверен, что это достижимо.
                            0
                            Ничто не мешает. Но некоторые вещи придется копи-пастить при использовании модели, либо использовать более громоздкие синтаксические выражения. Принципиально нового видимо DSL ничего не принесет, это только оптимизация.
                              0
                              почитайте примеры из статьи про DDD:
                              habrahabr.ru/post/142491

                              Суть такая если у вас исходная задача на языке предметной области:
                              Зарплата сотрудника = отработанное время * нормочас и т.п.

                              То в случае, если вы пишете чисто на коде, используя конструкции SQL, Linq и т.п. То задачу вы, наверное, решите, но корреляции между вашим кодом и языком предметной области будет очень мало, и в случае если у вас поменяется формулировка задачи (новые термины, связи между ними и т.п.) — то очень высока вероятность, что ваш код придётся очень серьёзно переделывать под нужды новых терминов.

                              В случае же, если вы имеете свой метаязык, который уже достаточно глубоко эмулирует язык предметной области и вы действительно решаете задачу на этом метаязыке: Salary(Person) ::= WorkedTime * PayPerHour… — то в случае, если задача будет переформулирована, есть вероятность, что вы новое решение запишите просто повторяя формулировку новой задачи при помощи средств метаязыка, без необходимости серьёзной перестройки своей метамодели (ведь она уже эмулирует задачу! только немного расширить надо). Ну и, конечно, чтение кода на метаязыке должно быть практически таким же комфортным, как чтение оригинальной постановки задачи на языке предметной области, т.е. это может делать даже не программист, а эксперт предметной области.
                                0
                                «Может кто разъяснит, что мешает реализовать модель предметной области (Model Driven Design — техническую часть DDD) средствами самого языка программирования, не прибегая к метапрограммированию?»
                                То, что вы (обычно) не можетеотдать полнофункциональный язык программирования нетехническому специалисту предметной области.

                                Но вообще, вопрос поставлен неверно. Для реализации DSL сначала нужна модель предметной области, реализованная любым способом, а потом написанный поверх нее DSL, который будет предоставлять пользователю максимально прозрачный и очевидный способ выражения задач.
                                  0
                                  Ничего не мешает. Просто появляется возможность наделить IDE дополнительными «знаниями» об элементах вашей программы. Например, если вы пишите на языке Java, то ваша IDE «знает» только о классах, методах, аннотациях и т.п. Соответственно и рефакторинги, навигацию и подсказки она может выполнять только для элементов языка Java. Что происходит, когда в вашей IDE появляется поддержка некоторой технологии, например, Spring? Она «узнает» о дополнительной семантике вашего кода, и получает возможность, например, искать использования класса не только в Java-коде, но и в XML-файлах Spring.

                                  Конечно, вы можете наделить IDE знаниями о дополнительной семантике конструкций вашей программы, самостоятельно написав плагин для Eclipse или IntelliJ IDEA, но в MPS сделать это значительно проще.
                                  –1
                                  Ого го, как далеко подкат.
                                    +1
                                    В статье было заявлено, что Lisp не решает проблемы из-за отсутствия языковой инфраструктуры. Можно подробнее об этом? Мне, просто, кажется что Lisp-подобные языки как раз самое лучшее, что придумали для поддержки DSL.
                                      0
                                      LISP пожалуй это простой молоток, с одним механизмом манипулирования списками. «Слойнойсть» абстракций на одному уровне, все смешивается имхо.
                                        +2
                                        Просто вместо «абстрактного» Лиспа 50-летней давности надо рассматривать нечто современное, Clojure, например. Там вполне удобоваримые макросы, на которых замечательно пойдёт этот самый language oriented programming.
                                          0
                                          Да, макросы это и есть главный инструмент для построения DSL.
                                      +2
                                      когда речь заходит о DSL'ях, вспоминается байка:
                                      С востока люди пришли на землю Сеннаар (в нижнем течении Тигра и Евфрата), где решили построить город (Вавилон) и башню высотой до небес, чтобы «сделать себе имя». Строительство башни было прервано Богом, который создал новые языки для разных людей, из-за чего они перестали понимать друг друга, не могли продолжать строительство города и башни и рассеялись по всей земле. [1]
                                      как вы считаете, грозит-ли подобная участь многоязыкому YouTrack, и если нет, то — почему? )

                                      какие KPI можете посоветовать для управления такой разработкой — в каких случаях стоит писать DSL, и это будет оправдано, а в каких нужно сказать «стоп» и тупо кодить?
                                        0
                                        Внедрение DSL становится неоправданным тогда, когда он начинает разрастаться до полноценного языка программирования и становится слишком универсальным и ваш проект начинает превращаться в yet another universal enterprise platform.

                                        А вот когда DSL используется для четко определенной и частой задачи (ETL, например) и не вылазит за ее рамки — все как правило должно окупиться.
                                          0
                                          с первым пунктом соглашусь не полностью
                                          если у вас очень объёмная задача, то создание своего языка тоже может быть оправданно, язык должен давать:
                                          1. возможность решения задачи на языке предметной области, особенно если требования предметной области часто меняются (вспомните 1С — аля платформа DSL языка для бухгалтеров, согласитесь писать все эти бухгалтерские заморочки на C# или того хуже на С++ было бы куда страшней и менее понятно).
                                          2. универсальность языка — любую задачу можно нарисовать на нём
                                          3. экспресивность языка — вы легко читаете задачу на метаязыке, как-будто задача написана на языке предметной области и т.п.
                                            0
                                            Тут мы уже начинаем плавно переходить к классическому холивару «универсальная платформа vs специализированная система».

                                            1. Проблема в том, что чем более универсален ваш язык — тем ближе он к тому самому языку на котором вы все пишете изначально и со временем превращается в отдельную платформу. А зачем писать еще одну (скорее всего более кривую) платформу, если она у вас уже есть? Тут уже проще подключить к проекту какой-нибудь скриптовой язык общего назначения типа Lua или Python.

                                            Из личного опыта разработки под 1С 7.7 (слава богу, уже более 10 лет назад ;)) и разработки под .net — под .net пишется лучше. Как минимум за счет инструментария платформы, не говоря уже о выразительности языка.

                                            2. Когда на DSL можно нарисовать любую задачу — это уже не DSL в общем-то ;) Противоречит определению. Во-первых, большой DSL и универсальный DSL долго изучать. Увеличивает порог входа для новых программистов. Во-вторых, у вас в проекте может быть множество маленьких язычков и это вполне нормально, более того, в книжках пишут, что разрастание dsl — это bad smell о том, что задача неправильно декомпозирована и dsl придется бить на несколько отдельных маленьких.

                                            3. Это один из самых больших плюсов DSL, да. Но чтобы так получилось, разработку нужно начинать с определения domain language.
                                          0
                                          На этот вопрос у меня заготовлен ответ. Отличительное свойство среды MPS — способность расширять языки, а не только писать их с нуля. То есть замена базового языка не предполагается.

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

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

                                          С помощью MPS вы можете добавить в IDE знания о своих библиотеках предметной области. И проблема «вавилонского столпотворения» угрожает вам в той же мере, что и без использования MPS. Не стоит в своем проекте использовать плохо совместимые технологии, и точно также надо стараться, чтобы код на ваших DSL выглядел единообразно.
                                          0
                                          тоже интересно было бы посмотреть сравнение решения задачи на классическом языке и на искусственном. что удастся сократить, на сколько и так далее.
                                          спасибо.
                                            –2
                                            никто не программит без использования IDE — личное дело каждого.
                                            у вас просто нет понятия как отказаться от этого говна
                                              0
                                              Выглядит заманчиво. Но куда интереснее было бы натравить подобную тулзу на существующий проект на той же Java и создавать DSL на основе уже написанного кода.

                                              Отсюда вопрос: в какой степени MPS на данный момент позволяет интегрироваться с существующим жавокодом?
                                                0
                                                Присоединяюсь к вопросу
                                                  0
                                                  Прекрасно позволяет. Можно подключить Java-код в виде исходников, можно — в виде скомпилированных классов или jar-файлов, а можно засосать Java-код в MPS и редактировать его уже прямо из MPS.
                                                    –1
                                                    А не подскажите, как же можно подключить существующий jar файл?
                                                    Я пытался написать небольшой проект для использовать JLink у меня не получилось…
                                                  0
                                                  К автору. Почему нас нет в списке продуктов на платформе MPS?
                                                  www.realaxy.com
                                                    0
                                                    Простите, неаккуратно получилось. В ней нет ни про вас, ни про Маркуса Фёлтера. Но я упомянул вас в одном из комментариев выше.

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

                                                  Самое читаемое