Ад спортивных программистов?

[metaclass]

http://dev.by/blogs/main/kuda-uhodyat-chempiony-sportivnogo-programmirovaniya
"НТ ООО «ЛюксСофт». Инженер-программист. В последнее время занимаюсь разработкой предметно-ориентированного языка программирования для нашего продукта."

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

Comments

[aliaksei-danchanka.myopenid.com (from livejournal.com)]

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

Мы делаем, грубо говоря, средство разработки бизнес-приложений, официально это пока называется у нас "платформа разработки информационных систем". Наша платформа имеет довольно своеобразную (если сравнивать с 1C, SAP ERP и т.п.) концепцию, базис и терминологию. Для описания бизнес-логики используется в основном function-level programming. В целом, если совсем грубо, вычислительная часть выглядит так - описывается декларативно бизнес-логика, при старте сервера из этого описания строится некая внутренняя модель, которая затем оптимизирующим компилятором преобразуется в выполняемые в run-time SQL запросы.

Теперь по поводу DSL.. Описывать бизнес-логику будут пользователи системы. Да, можно было предоставить им некий библиотечный fluent interface на той же java, на которой написана сама платформа. Но у нас все-таки довольно своеобразные принципы описания логики, которые слабо отображаются на языки общего назначения, поэтому все их преимущества (например, готовые IDE) практически нивелируются. DSL нам позволил отобразить все наши концепции напрямую в более-менее лаконичные синтаксические конструкции, хорошо понимаемые при условии понимания нашей платформы. Код на языке общего назначения без этого понимания выглядел бы, на мой взгляд, такой же абракадаброй, но только еще со своими синтаксическими и логическими ограничениями.
Другая причина заключается в желании обеспечить как можно более низкий порог вхождения для потенциальных пользователей системы, а это где-то уровень 1С/ABAP-программистов и толковых бизнес-аналитиков. Обычно для них язык общего назначения - такая же непонятная хрень, как и DSL, более того, у некоторых нет даже технического образования. Сейчас у нас пишут логику на DSL четыре бизнес-аналитика, программистами они не являются.

[theiced.livejournal.com]

беги оттуда :)

[blackyblack.livejournal.com]

Добрый ты сегодня.

[metaclass.livejournal.com]

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

И, в конечном итоге, я сейчас для таких целей использую eDSL (на Clojure) - чтобы не изобретать отдельный язык, инструменты для него, иметь сразу под руками все библиотеки, итд.
В теории, из этого можно было бы сделать инструмент для "не-программистов", но проще, имхо, их обучить языку :)

[vp.livejournal.com]

Извините, но мы ту все и каждый по разу в жизни писали DSL, и позвольте с вами не согласиться. Всякие речи, где говорится про "порог вхождения для потенциальных пользователей системы" - это миф на корю. ВСЕ языки на этом свете делятся на более и менее убогие. Как вы ни крутите, но язык, в который вложено 100 человеко-лет в разработку и проектирование, будет менее убогим, чем любой другой DSL, который суть побочный продукт. У вас же конечная цель не разработка языка? Нет, это всего лишь средство. Потому я с сегодняшней колокольни я только за интеграцию готовых языков.
И поверьте, нет ничего проще, чем ваш пользователь по шаблону накропает на каком-нибудь питоне несколько строчек.

Второе. Ваша фраза "все их преимущества (например, готовые IDE)" - это вообще не от мира сего. Наличие IDE и ЯЗЫК - это никак не связанные вещи.

[raydac.livejournal.com]

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

[justy-tylor.livejournal.com]

Распространённое заблуждение "не-программисты будут писать какую-то логику". Результат всегда печален.

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

Что же касается специфики предметки, то выгоднее сделать её в виде библиотеки/EDSL к встраиваемому языку общего назначения.

[blacklion.livejournal.com]

EDSL к встраиваемому языку общего назначения.
Если этот язык позволяет просто в себя впихнуть выразительный eDSL. Много таких?

[justy-tylor.livejournal.com]

Из распространённых - Lua, Python, Ruby, лиспы.

[blacklion.livejournal.com]

Лиспы? Только с ридер-макро (не путать с просто макрами лисповыми). Ох. Ну да, там что угодно можно делать.

В Lua, Python и Ruby будут болтаться ошмётки по сторонам по сути не нужные, и оставленные только что бы удовлетворить парсер языка, я уверен на 100%. Ну или язык будет встраиваться в строку типа eDSLEval("..."); :)

[justy-tylor.livejournal.com]

Про ошмётки всё верно. Эта цена платится за возможность в одной строке работать на уровне запросов ISO 15926, а в следующей работать с результатами в терминах множеств и алгоритмов хост-языка.

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

[blacklion.livejournal.com]

Не нужна ни в каком конкретном проекте универсальная расшряемость, вот в чём дело-то!

[justy-tylor.livejournal.com]

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

Основная проблема с требованиями к расширяемости в том, что они сами имеют тенденцию расширяться. Была в прошлом одна история. Дизайнеры запросили возможность скриптовать игровые сценарии как последовательность перемещений и отдельных анимаций - "техник должен пройти оттуда сюда и нажать на кнопку, больше нам ничего не понадобится, точно-точно". Ребята сделали. Затем запрашивались всё новые и новые фичи, вводились паттерны реакций на события (услышал игрока, увидел игрока, сработал таймер, ...), дошло до полускриптованных битв роботов с киборгами. Когда меня перевели на руководство тем отделом, то DSL представлял собой ужасное нечто с ручными уникальными метками состояний на каждой строке. Удалось его несколько облагородить для оставшихся до конца проекта сценариев, оставив совместимость со старыми. Наиболее разумным решением было бы прямое применение Lua, благо он и так использовался в том проекте. Однако, в момент поступления задачи "техник нажимает на кнопку" некому было предугадать последствия.

[blacklion.livejournal.com]

Например, в приводимом вами примере было бы круто иметь язык НА ОСНОВЕ Lua (почему нет?) но с прямым описанием конечных автоматов в синтаксисе, нет?

[justy-tylor.livejournal.com]

Был свой препроцессор для Lua, и "подсахаренные" описания состояний использовались при разработке несценарных моделей поведения игровых персонажей. :)

[blacklion.livejournal.com]

И, кстати, добавить eDSL без кровываых ошмётков ради удовлетворения не нами придуманного синтаксиса обычно удаётся в Хаскеле. И я вполне знаю человека, который на этом колбасит коммерческий куод именно в таком стиле — eDSL под задачу, а дальше это выглядит как срипт на оченьт специальном но СРАЗУ ПОНЯТГНОМ языке. Нужен конечный автомат? Вот пролог, а вот конечный автомат скопированный из описанния протокола как етсь (И ставшщий КОДОМ, который проверяется на типы, компилируется, оптимизируется и всё это забесплатно практически). Нужен парсер? Вот пролог, а вот грамматика в EBNF, прямо как в стандарте на формат, копипастом из документации в код скопированная. И так далее.

[justy-tylor.livejournal.com]

Хаскель в синтаксическом плане хорош. Но для продвинутых программистов. Я бы не доверил специалисту-предметнику на нём писать (а потом бегать с логами ошибок компиляции).

[berezovsky.livejournal.com]

так они же принципиально новую систему создают, как можно сравнивать с существующими?

[metaclass.livejournal.com]

Сделают они лисп с интерфейсом для пользователя в конечном итоге :)

[berezovsky.livejournal.com]

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

[metaclass.livejournal.com]

Ааа, вспомнил, мы это еще чуть ли не пару лет назад обсуждали.

[aliaksei-danchanka.myopenid.com (from livejournal.com)]

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

[raydac.livejournal.com]

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

[justy-tylor.livejournal.com]

Принципиально новая "декларативная бизнес-логика с трансляцией в SQL"? Вы пропустили пару десятилетий.

[theiced.livejournal.com]

угу. ну хотя бы damgaard concorde xal ;]