Обсуждение

Это очень старая тема - с ней носятся чуть не с появления языков. Наворотов много - от разннобразных макрпроцессоров до всяких лисповских средств и форта. В O'Caml возможность произвольного расширения грамматики (равно как и написания парсера для quotations с нуля) встроена очень давно - Camlp4 (никакой особенной мощности это не требует). По-мелочи ей пользуются часто (всякий синтаксический сахар навешивают), крупное использование я знаю одно - в системе автоматического доказательства Coq сделано расширение для записи математических формул, с которыми она манипулирует. С практической точки зрения фича оказалась малополезной. Проблема упираетcя не в синтаксис, а в дизайн - а это-то как раз и сложно. Сделать парсер и так сейчас не проблема. Проблема - спроектировать семантику и отобразить ее во что-то разумное. Причем язык с хорошим дизайном imho снимает большую часть потребностей. Сложность жабского API в основном же не от "отсутствия синтаксиса", а от слабости языка.

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

С практической точки зрения фича оказалась малополезной. Проблема упираетcя не в синтаксис, а в дизайн - а это-то как раз и сложно. А почему интересно Java и .NET обросло набором DSL-ей: asp, jsp, разные xml-дескипторы. Или вы считаете, что все это все правильно писать внутри кода основного языка? :) Вообще, по своему опыту работы в JetBrains MPS, могу сказать что польза огромна. Можете посмотреть на наш язык для регулярных выражений, и скажите, неужели от таких фич толк нулевой? http://krlz.livejournal.com/39760.html#cutid1 Сделать парсер и так сейчас не проблема. Проблема - спроектировать семантику и отобразить ее во что-то разумное. ИМХО, сделать парсер не проблема, но реализация сервисов вокруг языка, таких как IDE поддержки, системы типов, разных видов анализа итп более чем сложно, и требует знаний, которых у большинства людей, работающих с предметной областью просто нет.

Этим всем рассуждениям уже много больше двадцати лет -- но к языковым Workbench вполне применимо общее тут рассуждение, что мощности машин раньше просто не хватало для создания мощных "проекторов" (редакторов нотаций и систем манипулирования с деревом программы). А теперь начинает хватать. Компьютерная революция только-только начинается. Да неправда. У того же Симони (Intentional Software) примерно в 2000 году была работающая Intentional Programming, но он решил отделиться от M$, чтобы делать все самостоятельно. Имхо, для того чтобы сделать Language Workbench нужно примерно столько же производительности, чтобы сделать WYSIWYG редактор. Там тоже используется дерево документа, итп вещи. Такие редакторы появились достаточно давно.

А почему интересно Java и .NET обросло набором DSL-ей: asp, jsp, разные xml-дескипторы. Или вы считаете, что все это все правильно писать внутри кода основного языка? Так именно потому что не все правильно писать внутри кода основного языка - смысл именно в том, чтобы ее вынести. На регэкспы я посмотрел - во-первых - я довольно долго разбирался, что это все значит. Во-вторых - в том же camlp4 изобразить точный аналог - вопрос несколько часов работы. Но характерно - кажется никто этого так и не сделал. В-третьих - есть альтернатива - сделать нормальный API: Ну выглядело бы оно тогда как-то так: open RegExp; let user = plus letdig in let domain = sep ~by:(str ".") plus letdig in matches s (cat [user; str "@"; domain] То есть оно конечно более громоздко, но не особенно. но реализация сервисов вокруг языка, таких как IDE поддержки, системы типов, разных видов анализа итп более чем сложно, и требует знаний, которых у большинства людей, работающих с предметной областью просто нет Так оно особенно никуда не девается. Либо оно приходит из целевого языка, в который транслируется, либо все равно надо писать самому. Я на MPS давно не смотрел - но вопрос - реализовать тот же ML (хотя бы ядро, или F#) на нем получится? imho MPS тут даст очень мало. Чем он, например, с анализом типов поможет? Вряд ли будет проще написания еще одного плагина для идеи или eclipse.

В этом смысле - возможно. Вопрос - нужен ли тогда вообще язык, или достаточно какого-то специализированного ui-билдера

Так оно особенно никуда не девается. Либо оно приходит из целевого языка, в который транслируется, либо все равно надо писать самому. Я на MPS давно не смотрел - но вопрос - реализовать тот же ML (хотя бы ядро, или F#) на нем получится? ML реализовать можно. Возможно будут некоторые проблемы с типами (в нашем движке сейчас не поддерживается let полиморфизм, потому что он нигде не был нужен). imho MPS тут даст очень мало. Чем он, например, с анализом типов поможет? Вряд ли будет проще написания еще одного плагина для идеи или eclipse. Для анализа типов у нас есть, кстати специальный язык. Задаются типовые уравнения и неравенства, которые потом решаются. В идее и eclipse такого нет (в Еclipse, кстати, вообще нет никакого нормального API для разработки языков, как в идее, хотя какие-то попытки у них предпринимались. Практически все что касается языков приходится писать заново).

в Еclipse, кстати, вообще нет никакого нормального API для разработки языков Не факт, что это недостаток. Зато он не навязывает структуру дерева и т.п. А идея навязывает свое дерево и т.п. На прошлые новогодние каникулы я оказался без дела и с чужим ноутбуком - смеха ради попробовал поддержать O'Caml - ядро языка с подсветкой ошибко, rename, навигацией и простеньким билдом сделал дней за 10. Ну дальше уже анализ типов надо было писать и каникулы кончились - забросил. Но если цена вопроса - пара недель - вопрос стоит ли ради этого отказываться от гибкости. Мне судьба MPS любопытна, но я в его не особенно верю -

Но если цена вопроса - пара недель - вопрос стоит ли ради этого отказываться от гибкости. Мне судьба MPS любопытна, но я в его не особенно верю - Ну это если делать достаточно простую поддержку пара недель. К тому же у вас опыт разработки тулзов все таки немаленький, так что что и как делать вы уже знаете. Люди же занимающиеся разработкой для одной конкретной области ничего этого не знают, и чтобы сделать сносную поддержку какого-нибудь DSL-я им могут потребовать месяцы. Еще один плюс это то, что если есть один язык в MPS, то написать к нему расширения очень просто. (regexp был написан за пару дней). С обычными текстовыми языками это затруднительно (особенно если хочется иметь свою IDE поддержку). Получается такой сетевой эффект. Мне судьба MPS любопытна, но я в его не особенно верю - MPS за год развился. Мы смогли добиться, что им можно пользоваться на больших проектах (у нас пишется большой проект на нем). Сделали языки для веба, работой с базой данных. Так что перспективы сделать что-то хорошее у нас есть.

Обратите внимание на основной посыл в приведенных ссылках: требуется три компоненты минимум -- репозиторий исходного кода, проектор конкретного DSL и редактор конкретного DSL. А юзерский интерфейс к конкретной программе -- это дополнительно (как я понимаю, реализуется средствами DSL построения юзерских интерфейсов, а также DSL построения редакторов ;) Вы почитайте, почитайте. А то разговор получается странный -- обсуждаете не пост, а что-то отвлеченное.

А вот поглядите видеоклип с тем же Симони который буквально проговаривает этот пассаж про мощность машин, которая позволяет Intentional Software делать то, что она сейчас делает -- буквально на пятидесятой секунде: http://www.beet.tv/2007/09/microsoft-forme.html

Спасибо за ссылку не видел это интервью ни разу. Хотя по моему он все-таки не прав. Он сравнивает CAD системы с Language Workbenches, но CAD системы появились достаточно давно и машины тогда были куда более медленнее чем сейчас, а вот Language Workbenches достаточно недавно. По моему тут работает тот эффект, что программы развиваются так, чтобы чуть притормаживать на самых современных компьютерах. Взять хотя бы новый офис.

Для CAD систем раньше использовались специальные мощные workstation, и фирма Bentley как раз развилась на том, что пыталась сделать софт, аналогичный софту Intergraph, но который шел на "обычных" компьютерах -- это тогда было очень передовой технологией. Так что вы не правы про CAD. Я боюсь, что вы просто слабо знакомы с промышленными приложениями. Они большие, и поэтому медленны. Обратите внимание, речь идет о многих тысячах строках экспертного и программного кода. Раньше такие приложения работали вообще на мейнфреймах, там и архитектура была другая -- более производительная. Поэтому пример ваш с Офисом вообще не в кассу. Не все на свете сводится к десктопам и майкрософту.

Не знал этого про CAD, почитал википедию узнал много нового. Хотя все-таки в году так в 95 мощнности обычных персональных компьютеров хватало чтобы запускать CAD системы. Тогда кстати Intentional Programming уже разрабатывалось. С офисом я сравнивая потому что Word устроен практически также как и редактор типа Intention Programming или нашего JetBrains MPS. Имеется дерево, в случае Word, дерево состоящее из докуменат, подсекций, парагрофов и в самом низу символов, или в случае Language Workbench в виде синтаксического разбора.

В 1995 фирма Silicon Graphics только-только начинала испытывать трудности со своими рабочими станциями. Так что все с распространением "обычных компьютеров" произошло немного попозже. И вы не путайте крошечное дерево (с минимальным количеством связей) даже большого вордовского документа с деревом для какой-нибудь пенсионной системы CapGemini. В вашем JetBrains MPS, скорее всего, больших промышленных программ (каких-нибудь финансово-складских приложений для небольшого заводика с филиалами) не писалось пока.

В 1995 фирма Silicon Graphics только-только начинала испытывать трудности со своими рабочими станциями. Так что все с распространением "обычных компьютеров" произошло немного попозже.Насколько я понял из статья в wikipedia, тогда уже появились первые CAD системы для PC. Пусть и убогие. Хотя может быть я не прав. И вы не путайте крошечное дерево (с минимальным количеством связей) даже большого вордовского документа с деревом для какой-нибудь пенсионной системы CapGemini. Судя по картинке которая имеется в презентации и тому, что они показывают код в Excel, а потом код на DSL, приложение большим не является, но использование DSL-ей сильно облегчает задачу написания этого кода. В вашем JetBrains MPS, скорее всего, больших промышленных программ (каких-нибудь финансово-складских приложений для небольшого заводика с филиалами) не писалось пока. Ну да для заводиков не писалось, но приложения порядка десятков миллионов узлов синтаксических деревьев есть. И есть возможность улучшить эти показатели как минимум на порядок. Тут работа с большими приложениями мало отличается от того, что делает обычное IDE, Eclipse, например или IDEA. Разница только в том, что отображается в редакторе, в IDE текст, у нас кусок дерева. Обычно много редакторов не открыто, поэтому вполне возможно было бы работать со всем этим на намного более медленных компьютерах, если все хорошо соптимизировать.

Про CAD опять же, мы про разный масштаб. Представьте какую-нибудь атомную станцию в том писишном CAD, или небольшой химический заводик, или даже нашу Башню Федерации из московского Сити со всеми ее нестандартными в силу кривизны деталями. Ваше дерево на десятки миллионов узлов -- ага, 2Gb памяти компьютера вполне достаточно, полусекунды на любой обход дерева вполне достаточно, экрана 1290*768 едва хватает для отображения нужных окошек. Теперь отъезжаем на всего десять лет назад (в 1998 год) и пытаемся понять, сколько тогда стоил бы такой компьютер, который все это тянет, и можно было бы его назвать персональным. И сколько лет бы вы оптимизировали код, чтобы хоть что-то у вас в крупном приложении проворачивалось за время 0.2 секунды (максимальное время отклика для действительно интерактивных приложений). От того же Eclipse мои знакомые разработчики стонут от неповоротливости на небольших офисных компьютерах куда им нужно ставить там разработанное -- уж очень, собака, требователен к аппаратуре. Вам бы практики промышленных приложений... ;)

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

Тут вопрос сводится к "Вам шашечки или ехать?". Понятно, что экспертам хочется рисовать картинки, да и программеры тоже часто любят их рисовать. Но вот автоматически генерировать более-менее адекватный код из этих картинок ни у кого не получается. Разве что, предметная область простая, но и тут для получения реального кода нужно тщательно прорабатывать детали (т.е. отлаживать код), для чего картинки уже неудобны! Причина этого понятна. Есть так называемый semantic gap между компьютером и человеком. Программист - переводчик с человеческого на компьютерный. Эксперт - обычно нет, поэтому он всячески сопротивляется попыткам сформулировать проблему точно, на достаточном для компьютере уровне, в частности норовить нарисовать картинку. Так что по любому, по этой картинки программеру придется код писать. Вот если бы на экспертов с их картинками можно было бы частично возложить работу по проверке спецификации с реальной прогой - это было бы круто.

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