Дмитpий Hecтepук

Блог о программировании — C#, F#, C++, архитектура, и многое другое

Гибридные DSL

leave a comment »

В наше время доменно-специфичные языки существуют 3х типов – текстовые (например на языке F#), структурированые (см. например JetBrains MPS и графические (DSL Tools, Intentional Workbench, и т.д.). У меня же появилась идея создания другого подкласса доменно-специфичных языков – гибрида текстового и графического языка.

Ода о конечном пользователе

На самом деле, идея о том что DSLи будут использовать доменные эксперты провальна, и вы это знаете. Каковы шансы научить эксперта какой-то определенной нотации лишь для того чтобы вы легче понимали друг друга? Примерно нулевой. Серьезно, в нашей аутсорсинговой среде никто заморачиваться не будет, все будут просто бюджетировать с учетом обучения в стиле “или вы к нам или наш эксперт к вам”. Расходы на создание DSLей и их внедрение а также обучение персонала никто вообще считать не будет.

Я считаю что DSLи нужны нам – разработчикам – чтобы легче справляться со своими обязанностями. Нам самим нужно лучше разбираться в нашем коде, поэтому в свое время были произведены язык UML и парадигма MDA. Только одна маленькая проблемка – UML и MDA непригодны для кодогенерации. Спорьте сколько хотите, но это в большинстве случаев так. А если вы не согласны, возьмите лидирующий тул для UML (Sparx EA) и попробуйте реверс-инжиниринг и генерацию кода. Или возьмите ArcStyler и попробуйте разобраться как там генерировать код. Уверен, вас ожидает провал, по крайней мере на уровне коммерческого использования а не “Hello World”.

Зато вот DSLи – это самое то для разработчика. Это, так сказать, метаразработка. Единственная проблема – это то что мы не видим и модель и конечный результат одновременно. Например, я пишу проектный план на F# но самого плана не вижу! Или, наоборот, я использую мою AsyncDsl для описания асинхронного алгоритма, но не вижу сам код, и даже не могу предположить, корректен он или нет!

Многооконная разработка

Хочу сделать небольшое сравнение. Вот сейчас я набираю статью, и у редактора 3 окошка – то, куда я печатаю, то как мой текст трансформировался (типографический постпроцессированный HTML) и собственно результат в контроле браузера (иллюстрация).

Такой подход имеет смысл и для DSLей. То есть суть в том, чтобы, с одной стороны, показывать “исходники”, но и о результате не забывать. Но тут возникает интересная проблема – если наша DSL генерирует код, то это может быть несколько файлов (или даже проектов), и показать их на одном экране попросту невозможно. Поэтому у меня возникла другая идея – достаточно показывать не сам код, а лишь его визуальное представление. То есть если мы говорим о написании тестовой DSL, то при каждом изменении исходого текста нужно отображать обновленное визуальное представление.

Гибриды на практике

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

edge alpha beta
edge beta gamma
edge alpha gamma
edge beta eta
edge gamma eta
edge alpha eta
edge xi beta

В принципе, эту же концепцию можно транслировать и на обычные DSL используемые для кодогенерации. Например, тем кому не нравится Workflow Foundation и то как там определены описания операций (а для простых сценариев это сделано действительно неудобно), можно дать возможность описывать свои алгоритмы исполнений с помощью тех же графов. Чем это лучше? Да тем, что работая с вашей DSL вы можете одновременно видеть и ее определение (в вашей собственной нотации), и ее визуальное представление. Представьте такую аналогию – вы пишете код, и на том же экране видите те диаграммы WF которые соответствуют именно этому коду.

Заточка под свои цели

Для того чтобы сделать свою DSL, нужен инстументарий который хорошо справляется с рисованием, как минимум, графов. Я для этого рекоммендую брать Microsoft Automatic Graph Layout или GraphiViz. Что касается парсера, тот тут все индивидуально – я пишу свои парсеры сам, хоть и знаю о существовании таких вещей как ANTLR которые помогают создавать парсеры из спецификаций. ■

Advertisements

Written by Dmitri

15 марта 2010 в 10:20

Опубликовано в dsl

Оставить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: