Как система JetBrains MPS позволяет достичь более широкого использование DSL-ей (языков специфичных для предметной области)

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


    Так что же такое DSL? DSL это язык, созданный для решения задач в определенной предметной области. DSL-ями являются большинство декларативных языков, которые решают задачки в узких предметных областях. Например, SQL, регулярные выражения, XPath, Prolog, формулы в Excel. К сожалению, на этом список широко используемых DSL-ей заканчивается. Основное достоинство таких языков в том, что благодаря близости их конструкций к предметной области, код на этих языках очень ясен и краток. Более того, чтобы редактировать код на таких языках, не обязательно быть программистом. Если человек разбирается в предметной области, то он легко может писать код на таких языках благодаря своим знаниям.

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

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

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

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

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

    Давайте рассмотрим пример. Допустим, 2 компании решили добавить поддержку интерполяции строк (интерполяция строк позволяет писать выражения внутри строковых литералов) в Java. Допустим, первая компания использует такой синтаксис:
    "{2+3}"
    А вторая такой:
    "${2+3}"
    Если мы будем использовать оба расширения одновременно, и введем такую программу:
    «Account balance is ${account.getBalance()}»
    то ее интерпретация неоднозначна. Является ли $ частью синтаксиса интерполяции, или частью строкового литерала? Пример несколько искусственен, но позволяет понять общую проблему неоднозначности, которая возникает при наличии похожего синтаксиса для разных конструкций.

    Чтобы добиться высокой производительности разработчика, необходимы интеллектуальные средства разработки. C появлением интеллектуальных редакторов, таких как в IntelliJ IDEA или в Eclipse, разработчикам бывает трудно переключится на редактирование текста в обычных редакторах. Текстовые редакторы не подсвечивают ошибки, не предоставляют контекстную помощь, не показывают меню с доступными вариантами, в них нет поддержки рефакторингов. Существуют фреймворки для создания интеллектуальных редакторов, например, IntelliJ IDEA Language API, XText, Oslo, но ни один из этих фреймворков не поддерживает расширяемые языки на должном уровне. Даже если нам не нужна расширяемость, создание поддержки языка с использованием этих средств требует хороших знаний в области языков программирования и занимает очень много времени. Как видно, инструментальная поддержка очень важна, но реализовать ее непросто.

    Давайте подведем итог: люди занимаются не тем типом DSL-ей; для достижения увеличения производительности необходимо расширять существующие языки программирования общего назначения. Создавать же такие расширения сложно из-за того, что широко распространенные технологии не поддерживают совместимость расширений друг с другом.
    Как JetBrains MPS решает указанные проблемы

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

    MPS решает проблему неоднозначности радикальным способом: если у нас нет текстовой грамматики, то у нас нет и неоднозначности. Такой подход, однако, не означает, что в MPS не используются грамматики. Вместо конкретного синтаксиса, в определении языка в MPS определяется абстрактный синтаксис (структура синтаксического дерева). Если вы знакомы с XML, то наверное знаете об XML Schema, которая напоминает способ описания синтаксиса, используемый в MPS.

    Поскольку при таком подходе невозможны неоднозначности, языки легко могут комбинироваться друг с другом. Вы можете расширить синтаксис языка новыми конструкциями. Вы можете вставить код на одном языке внутрь кода на другом язык, или даже вставить код на языке программирования общего назначения внутрь относительно замкнутого DSL-я. Это означает, что языки совместимы друг с другом, и это позволяет повторно использовать языки и их части, что возможно с большими проблемами в случае традиционных технологий. Мы в JetBrains много экспериментировали с такими повторными использованиями. В дистрибутив MPS входит большое количество расширений Java:
    • collections language, который позволяет более просто работать с коллекциями
    • dates language, который добавляет поддержку дат напрямую в Java
    • math language, которые позволяет писать суммы, произведения, итп математически конструкции

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



    Поскольку мы избавились от текстового представления, мы не можем использовать обычный текстовый редактор. Для работы с кодом мы используем специальный проекционный редактор. Для каждого узла синтаксического дерева, он создает проекцию — часть экрана с которой может взаимодействовать пользователь. При разработке MPS были приложены огромные усилия для того, чтобы такой редактор вел себя настолько близко к тестовому редактору, насколько это возможно. Например, если вы введете 1 + 2 + 3 в MPS, вы получите тоже синтаксическое дерево, которое было бы получено при разборе этой строки в Java. Конечно, проекционный редактор отличается от текстового, и существуют вещи, которые возможны в одном и невозможны в другом, и наоборот. Несмотря на это, к этим различиям можно привыкнуть, не теряя в производительности. По нашему опыту, требуется около 2-х недель чтобы стать продуктивным в проекционном редакторе.

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

    Внутри JetBrains мы используем MPS для разработки коммерческих проектов. Наша новая система учета ошибок, с кодовым именем Харизма, создана полностью на MPS, и это только начало.
    Заключение

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

    MPS 1.0 был выпущен в июле. Большая часть кода доступна под лицензией Apache 2.0 (за исключение JetBreains IDE Framework, лицензия которой позволяет использовать MPS в продуктах на основе MPS, не покупая каких бы то ни было лицензий у JetBrains).

    Вы можете скачать MPS отсюда: www.jetbrains.com/mps и начать создавать языки прямо сегодня.

    P.S. Мы ищем старшего разработчика в проект. Подробности в вакансии в моем профиле.

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

    Средняя зарплата в IT

    120 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 6 371 анкеты, за 1-ое пол. 2021 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

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

      +3
      Я, видимо, так и не смогу понять всей идеи до конца, без конкретного примера. Уж сколько читаю, много слов о том, как может быть улучшена разработка, чем лучше редактировать AST, но примера, наглядно показывающего, как можно получить результат с куда меньшими затратами, чем от обычного ЯПа, не видел.
        0
        Вы пользуетесь SQL или XPath? Теоретически, код на SQL, можно было бы заменить императивным кодом, который бы обращался к индексам базы данных, просматривал записи, итп, но в реальности никто этим практически не занимается (есть правда berkeley db, где можно все это сделать руками), тк SQL намного короче и понятней из-за близости к предметной области. Аналогичная ситуация с XPath.
          +1
          Ну, я понимаю, зачем нужны DSL, я не понимаю, как MPS радикально упрощает их создание. Их вон что на лиспе, что на немерле, что на хаскеле клепают (и даже на C++), и текстовое представление вроде не было самой большой проблемой.

          Попробую посмотреть презентацию.
            +1
            Лисп решает проблему парсирования путем существенного ограничения синтаксиса, а это не всегда приемлемо. Например, сделать язык регулярных выражений чисто на s-выражениях, конечно, можно, но использовать это будет тяжело. Другая проблема это то, что лисп динамически типизированный язык, и поэтому сделать мощную IDE поддержку к нему тяжело.

            Насчет хаскеля. То, что можно сделать на нем называется internal DSL-ями. Они возможны в принципе на любом языке, но более всего распостранены в питоне, руби итп. При этом подходе, конструкции основного языка используются для создания языка, но опять же, мы ограничены синтаксисом базового языка. Вставить, например, значок суммы, в язык мы не можем.

            C немерле все хитрее. В немерле есть макры, но к сожалению, они позволяют добавлять только новые типы выражений, и имеют довольно ограниченный синтаксис. Туда нельзя вставить, например javascript, как мы постоянно делаем в charisma (посылаем javascript на клиент с сервера, чтобы его выполнить там). Вобщем, в немерле все лучше, чем в языках, где обычно делают internal DSL-и, но все равно далеко от идеала.
              +1
              >> Туда нельзя вставить, например javascript, как мы постоянно делаем в charisma (посылаем javascript на клиент с сервера, чтобы его выполнить там).

              о, восхитительно! тут теперь бы побольше подробностей… JS пишется прямо среди Java кода? захватывает переменные из окружающего java контекста?
                0
                Да, именно так.
                  +1
                  Тогда такой вопрос в сторону… Предположим есть нужда поиграться с системой типов Java (добавить туда скажем value type) и сделать из него удобный язык системного программирования (нечто аналогичное тому, что делают в Jikes, см. например Demystifying Magic: High-level Low-level Programming...)… Поможет ли тут MPS или надо всё-таки пилить компилятор (e.g. javac)?
                    0
                    Это можно сделать и на MPS. Можно, разворачивать переменные valuet type-а на несколько локальных переменных.
                      +1
                      а насколько это сложно вообще? т.е. если я хочу, чтобы для некоторого типа T выражение expr.f, где expr имеет тип T, преобразовывалось в Util.getWordAt (Util.address(expr), offset_of_f) на этапе компиляции/трансляции (где offset_of_f задаётся скажем аннотацией), много ли бы мне понадобилось кода написать?

                      а вообще я чувствую это прикольно, если бы я не уволился, то скорее всего постарался бы убедить коллег (и начальство) использовать MPS в нашем начинании… а то пилить javaс не так кошерно, как получить IDE поддержку сразу из коробки…

                        0
                        Для того, что вы описали, много кода не потребовалось бы. Простая замена вроде того, что вы описали, реализуется очень просто.
                        0
                        Правильно ли я понимаю, что при помощи MPS можно ввести в Java value types, которые будут размещаться не в куче, а на стеке (1), для которых будет автоматически осуществляться boxing/unboxing (2)?
                        Каким образом возможно реализовать данную функциональность, ведь для этого требуется серьезная модификация самой виртуальной машины и (возможно) байт-кода Явы?
                          0
                          Ну, например, если у нас value object на стеке, мы можем делать из него набор примитивных локальных переменных.

                          Например, был код

                          vector v =…

                          а мы сгенерировали из него

                          int _v_x =…
                          int _v_y =…

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

                          Таким образом, кстати, когда-то умел работать Microsoft JVM.
                            0
                            Хм… Таким образом все-таки получается, что ни один DSL, разработанный при помощи MPS, в реальности не может «выпрыгнуть» за пределы JVM и лишь является своего рода транслятором расширенного синтаксиса (представленного в виде семантического дерева) в Ява-код с последующих компилированием?

                            И еще вопрос: не является ли более разумным использование некоего валидатора различных DSL-расширений на предмет неоднозначности синтаксиса, чем использование специального редактора для ввода напрямую синтаксического дерева?
                              0
                              >Таким образом все-таки получается, что ни один DSL, разработанный при помощи MPS, в реальности не может «выпрыгнуть» за пределы JVM
                              Это не верно. MPS абсолютно language agnostic. У нас есть, например поддержка javascript. Генерить и расширять можно любой язык, если он реализован в MPS. С Java мы просто больше всего эксперементировали.

                              >И еще вопрос: не является ли более разумным использование некоего валидатора различных DSL-расширений на предмет неоднозначности синтаксиса, чем использование специального редактора для ввода напрямую синтаксического дерева?
                              Это плохое решение, по крайней мере для той задачи, которую мы решали, потому что мы не можем совмещать языки друг с другом, как мы могли бы делать с библиотеками.
                                0
                                Я немного запутался.
                                Наверное я не совсем правильно понял, в моем представлении MPS — это некий транслятор, позволяющий использовать произвольные расширения языка, которые потом транслируются либо в примитивы этого языка, либо в байт-код. Или у Вас MPS также выполняет роль виртуальной машины или статического компилятора?

                                Не совсем понятно, почему это «плохое решение». Какими критериями Вы руководствуетесь для его оценки? Я, честно скажу, пока не пробовал Ваше решение (а попробую я обязательно и с удовольствием, я собираюсь писать по DSL диплом), но мне вот так субъективно кажется, что вводить сразу конструкции в виде семантических деревьев, это как программировать использую Postfix-нотацию — привыкнуть да, можно, но все-равно неудобно. Нет?
                            0
                            если говорить про конкретно наши планы, то там предполагалась в том числе и модификации в нашем Java AOT-компиляторе, просто он принимает на вход не source code, а JBC, поэтому требовались протычке уже на этапе компиляции (в javac), ну и дополнительно хотелось сразу же на высокоуровневом представлении сделать проверки типов и другие радости (я даже помню воскресным вечерком накидал proof-of-concept плугины для Idea & Eclipse; хотя там и возникли потом проблемы с рефакторингом...).
                              0
                              О, как интересно!!!
                              Таким образом вы используете все эти расширения только при статической компиляции? Если нет, то какую JVM вы используете?
                              Кстати, ваш компилятор находится под какой лицензией?
                                0
                                я участвовал в обсуждении проекта (можно сказать, что я был одним из идеологов такой архитектуры), но уволился до того как проект начали реализовывать.

                                всё это планировалось делать в рамках Excelsior JET, на данный момент код его закрыт…
                    0
                    Вставить, например, значок суммы, в язык мы не можем

                    Если речь о юникоде, то вроде как можно, но думаю, что тут подразумевается что пошире. Однако это ведь вопрос представлений. Например, в хаскеле очень многое (в том числе автоматом) поддерживает класс Show и может быть выведено строкой. Формально, можно завести класс Edit, специальная реализация которой будет в вашем редакторе матрицу отображать матрицей и позволять её именно так редактировать. Однако это займет много времени, а толку мало.
                    Если я правильно понимаю, недостаток, например, compile-time преобразования строки (например, в TH или Nemerle) (а уж там можно назадавать любой синтаксис) в том, что это не будет поддерживается IDE?
                      0
                      А если хочется у суммы сабскрипт и суперскрипт поставить? Или хочется в код вставить диаграмму? Все это легко можно реализовать в MPS.

                      >Если я правильно понимаю, недостаток, например, compile-time преобразования строки (например, в TH или Nemerle) (а уж там можно назадавать любой синтаксис) в том, что это не будет поддерживается IDE?

                      Да нет, с этим все нормально, проблем нет. Например, IDEA, умеет понимать regexp-ы, когда они находятся в правильном контексте, и подсвечивать синтаксис внутри них.
                      0
                      Туда нельзя вставить, например javascript, как мы постоянно делаем в charisma


                      Вставить Javascript, чтобы послать с сервера на клиент, можно в любом языке, в котором поддерживаются строки:) Или вы написали расширение, которое отображается на Javascript? В таком случае, это можно сделать и на Nemerle: определить расширения синтаксиса языка, которые сами по себе не выполняют никаких действий, но выглядят так, что бы их комбинация походила на Javascript. Затем пишется макрос, который на вход принимает такой JS-like экспрешен анализирует его, так как у него есть доступ к AST и транслирует в JS. Можно вообще транслировать таким образом сам код Nemerle в JS.
                        0
                        Да, javascript у нас не обычный, а расширенный классами. А что с IDE поддержкой всего этого чуда?
                          0
                          Будет подсветка, если мапить код на Nemerle, то и Intellisence.
                            0
                            Вы про какой вариант? Про внутри строк? Или про трансляцию nemerle в javascript?
                              0
                              Про трансляцию Nemerle и/или расширении его новым синтаксисом.
                                0
                                Эффективная трансляция в javascript это очень непростая задача.
                            +2
                            Подсветка будет, но про авто дополнение соврал — с макросами работаю мало: в текущем проекте парочка, что бы улучшить синтаксис (добавить flat map как оператор) и один посложнее, для преобразования AST.

                            Сейчас попробовал добавить поддержку вставки чего-то JS подобного в Nemerle:


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

                            Из своего опыта разработки на Nemerle, понял, что добавление синтаксического сахара предоставляет некоторые удобства, но усложняют чтение кода по прошествии некоторого времени, так как нужно помнить, что же я имел ввиду этой закорючкой: "<+". Наиболее ощутимый результат дало применение макросов, которые сокращают рутинные шаблонные операции, например, объявление Dependency Properties при разработке интерфейсов или автоматическая реализация методов source.CopyTo(T target), где source имеет тип T. Но эти изменения происходят до предметной области — на уровне реализации. Отчасти это вызвано тем, что существует закон Мерфи: любая спецификация всегда изменяется, а из этого следует, что изменять каждый раз DSL в соответствии с изменениями в спецификации, вместо того, что бы писать код, устойчивый к ним, затратно.
                              0
                              Интеллектуальные IDE это не подсветкак синтаксиса с автодополнением. Это навигация, find usages, рефакторинги, подсветка ошибок и инспекции кода.

                              Но, вообще, прикольно. Способ решения проблемы поддержки языко-ориентированного программирования, не таким способом как у нас.
                    0
                    Возможно вас заинтересует моя презентация про MPS. Там больше примеров: vimeo.com/4844789
                    +1
                    Отлично для новичков, жаль что я этот текст читал уже много раз (8
                      0
                      Это перевод моей статьи, да. Я его, правда, немного улучшил :)
                      +1
                      >> Наша новая система учета ошибок, с кодовым именем Харизма, создана полностью на MPS, и это только начало.

                      о! это уже интересно. нельзя ли поподробней?

                        0
                        Вот ее работающая копия: www.jetbrains.net/tracker Попробуйте ввести в строке, например MPS unassigned unresolved
                          +1
                          Харизму-то я давно видел… замечательная штука.

                          вы мне предлагаете изучить как MPS применяется в Харизме по ишуям? o_O
                            0
                            К сожалению, харизма сейчас коммерческий проект, так что сорцов мы не выложим. Но, вероятно, в ближайшем будущем языки, на которых сделана харизма будут сделаны публично доступными.
                              +1
                              Да про сорцы мне тоже всё понятно было. Но ведь чтобы описать как там MPS применяется совсем не надо сорцов выкладывать.

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

                              А вообще прикольная у вас контора, на острие прогресса так сказать…
                                +1
                                Попробую в будущем что нибудь такое написать, где было бы видны плюсы мпса. Возможно, какие нибудь фрагменты кода из харизмы.
                                  0
                                  вы мне душу разбередили, теперь я борюсь соблазном не ждать, пока вы напишете статью, но зааплаится к вам… дабы посмотреть на всё это счастье своими глазами =)
                        –2
                        Зачем это нужно, когда есть Scheme?
                          0
                          Допустим, я хочу иметь сильно типизированный язык, с красивым синтаксисом, и хорошей IDE поддержкой. На scheme и lisp это плохо реализуется.
                            –3
                            > сильно типизированный язык

                            Лиспов много.

                            > красивым синтаксисом

                            Синтаксис прикручивается любой.

                            > хорошей IDE поддержкой

                            emacs
                            0
                            зачем нужно Scheme, когда есть это?
                              –1
                              Толсто.
                                +4
                                можно подумать у вас тонко =)

                                зачем нужен mraleph, когда есть nikitad; зачем нужен nikitad, когда есть mraleph.
                                зачем нужно A, когда есть B?
                                зачем легион редакторов и еще больше языков программирования?

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

                                неужели это не прекрасно?
                                  –2
                                  Судя по описанию это MPS по возможностям в плане разработки DSL есть неполноценные лиспы с визуальными свистоперделками. Но Сергей Дмитриев — молодец, берет деньги за то, что уже много лет существует бесплатно.
                                    +2
                                    во-первых, как показывает жизнь визуальные свистоперделки иногда имеют значение.
                                    во-вторых, MPS как таковая бесплатна, хотя нужно купить, наверное, идею…
                                      +1
                                      MPS бесплатен, заопенсорсен, и более того, отлично работает без идеи.
                                        0
                                        неожиданно. я полагал, что это плугин к идее…
                                          0
                                          Он сделан на основе JetBrains IDE Framework. Этот фреймворк был выделен из IntelliJ IDEA, чтобы создавать новые IDE. Кроме MPS, есть наше Ruby IDE, RubyMine, и в ближайшем будущем будут еще IDE.
                                        +1
                                        > во-первых, как показывает жизнь визуальные свистоперделки иногда имеют значение.

                                        В данном случае они излишни. На лиспах можно спокойно за неделю наделать целую кучу микроязычков «для разработчика», с помощью которых сильно облегчить себе жизнь при разработке непосредственно самой программы. Можно встроить лиспы непосредственно в свою софтину и использовать их в качестве ДСЛ, и при этом продолжать испольвать Си или жабу или еще чего (так сделано в емаксе). При этом к языкам даже не обязательно прикручивать синтаксис — можно спокойно использовать синтаксис лиспа как представление АСД.

                                        В случае с MPS разработчик во первых — привязан к языку, во вторых — привязан к «Идее».

                                          0
                                          ваш подход имеет право на существование.

                                          но в случае больших проектов/консервативных сотрудников наличие IDE может играть существенную роль. я сам был участником группы, которая проектировала DSL, и пришлось пойти на ряд компромисов, чтобы не потерять поддержку в IDE.
                                            0
                                            А как вы интегрировали свой DSL в используемую IDE? В том же Емаксе это достаточно просто — тут и разукрашка синтаксиса будет, и автодополнение. Если постараться — то даже тегирование в ECB можно добавить и удобный рефакторинг.
                                              0
                                              пришлось сделать DSL синтаксически не отличающимся от Java.
                                                0
                                                ИМХО, это нехорошо.
                                        +1
                                        ну и кстати: нужно вам расширить синтаксис Java, вы что будете делать? парсер Java на Lisp'е писать?

                                        а нет! я знаю… вы на Lisp'e напишите конвертер Java-to-Lisp (и может даже Lisp-to-Java), а потом продолжите на Lisp'е колбасить =)
                                          –1
                                          Нет, я возьму лисп, компилирующийся в байткод JVM, напишу что нужно, а потом буду вызывать это из самой основной программе на джаве.
                                            0
                                            ах, да… про всякие Closure я вечно забываю.
                                              0
                                              Про него как за не надо забывать, забывать надо Common Lisp, как устаревший и неудобный во многих случаях из-за недостатков стандарта, монстроузности, большой бедой с документацией в библиотекам, отсутствия нужных стандартизированных библиотек (например, для гуя), кривоватой реализацией модулей и пространств имен.
                                +1
                                а как дела с системами контроля версий? и вообще что является результатом работы в «проекционном редакторе» и как в этом результате решается вопрос конфликта грамматик?
                                интересно былобы узнать подробней про «проекционный редактор»
                                  0
                                  Мы поддерживаем все version control системы, которые поддерживает IntelliJ IDEA. Единственное условие, для того, чтобы это все хорошо работало, все действия желательно делать из IDE. У нас есть и дифф и мерж. Более того, наш мерж может разрешить больше конфликтов, чем обычный текстовый мерж.

                                  А что хочется узнать про проекционный редактор? Какая-то информация есть здесь: www.jetbrains.net/confluence/display/MPS/Editor Но, если вы хотите знать подробности, то советую скачать исходники, и посмотреть как он работает.
                                    0
                                    т.е. все файлы в итоге хранятся в спецформате (каком?) и дифф/патч реализуются «не стандартными» утилитами (собственно вашим редактором)?
                                      0
                                      Формат основан на xml. Вот его кусочек:

                                        0
                                        формат закрытый?
                                        кстати хабр схавал xml =)
                                          0
                                          Да нет не закрытый. Проект опен сорсный. В принципе, можно выдрать оттуда читалку/писалку, и использовать его в похожей системе.
                                            0
                                            а хотябы ссылочку на описание формата или название чтоб погуглить?
                                              0
                                              Ссылочки нигде нет. Единственный источник это исходники MPS-а (скачиваются с сайта).
                                        0
                                        А представление диффа и мержа, да на основе нашего редактора.
                                    0
                                    Все конечно очень классно, но порог входа для написания какого-нть Hello World под MPS, ИМХО, просто нереальный.
                                      0
                                      Здесь вывесили два видео об MPS: http://habrahabr.ru/blogs/development/135119/

                                      Возможно, смотреть их будет проще, чем читать текст. Там живая демонстрация кода.

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

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