Обсуждение

В идеальном мире в программах нет ошибок, специалисты разбираются в предметной области (к тому же обладают логическим мышлением и не боятся нового), а универсальность ничего не стоит. Реальность, к сожалению, немного отличается. Система созданая универсально с кучей базовых идей и удобная для предметной области или производит негодный продукт, или приходится вызывать специалистов, которые под замечательными правильными диаграмками роют кротовые норы и заставляют этого монстра худо-бедно работать. Из наиболее известных примеров - внедрение САП. Так что самый экономичный и правильный вариант - создание силами небольшой команды серъёзных спецов басейна-лягушатника, где резвятся и "специалисты предметной области" и "специалисты по применению ИТ в предметной области". А такой лягушатник проще, удобнее и экономичнее строить на универсальных языках программирования, без всяких мета-пирамид. Для предметной области берутся библиотеки, которые склеиваются правильным программистским кодом. НО, мы не ищем лёгких путей и специалистам по САП тоже надо зарабатывать на свой хлеб. С маслом. И толстым слоем икорки.

В программах примерно 1 ошибка на 1000 строк кода, но это не зависит от языка, специалистов я в данном тексте поделил на три категории (специальность и специализация, а потом просто пользователи), а универсальность стоит ровно столько, насколько правильная архитектура ее обеспечения и что под ней вообще имеется ввиду (машинный код универсален, нет? Он, наверное и есть самый дорогой в цене универсальности, раз без него не обойтись? ;) Внедрение SAP имеет отношение (в терминах введенных в данном посте) к выбору языка технологической платформы языка приложения. В SAP приходится откатываться с языка приложения (который неадекватен используемым в бизнесе процессам) на язык технологической платформы, и затем заново вышивать крестиком язык приложения. А поскольку речь идет не гладкой стыковке всех используемых языков приложений и несовместимости технологических платформ (каждая из них -- отдельный модуль "предметной области"), то вместо ожидаемого внедрения в бизнес сначала получается неожиданного этапа глубокой софтверной проработки с решением проблем моделирования предметной области на неудобном для этого софте. То, что пишу тут я -- это переход как минимум на удобный для этого софт, а также какую-то фиксацию языка, в котором ведется обсуждение подобных работ с DSL. Так что SAP в текущем состоянии как раз является примером того, к чему ведет отсутствие ясного понимания в обсуждаемой предметной области DSL (и SAP очень интересуется обсуждаемым в данном постинге вопросов -- см., например, на организованный SAP семинар по DSL, http://krlz.livejournal.com/74069.html: SAP делает свою DSL-инфраструктуру, и приглашает разработчиков других подобных систем на обмен опытом). Предложенный вариант с лягушатником из программистов и спецов правильный, только у нас немного разные понимания "универсальных языков программирования". Вот я до сих пор с нежностью вспоминаю свой опыт работы на Forth -- это для меня как раз универсальный язык программирования, потому что на его основе делались DSL, и уже в их терминах решались задачи. Очень удобно, быстро, надежно. Там, правда, были другие проблемы, но они были связаны не с этим свойством языка. Мне еще кажется, что язык всего этого "метамоделирования" и "доменориентированности" очень мутный и не позволяет людям понимать, о чем идет речь. Я в данном постинге попытался чуть-чуть поработать с терминологией, чтобы можно было обсуждать DSL-часть, ибо она тоже многоуровневая получается. Кстати, я явно имел тут ввиду очень похожий на SAP комплекс 1C (как минимум -- Бухгалтерию), но который является очень успешным именно за счет того, что язык бухгалтерской учетной технологической платформы была выбран очень грамотно (см. приведенную в постинге ссылку), и DSL приложения РСБУ (российской системы бухгалтерского учета), написанный на языке бухгалтерской технологической платформы поставлялся в составе системы. Опыт был настолько хорош, что 1С, как система DSL-программирования, была повторена специалистами Михаила Донского на наладонных компьютерах и довольно быстро там работала. У SAP этого всего нет, отсюда и беда. Так что спасибо за возможность это откомментировать ;)

Честно говоря, я не могу вести серьёзный разговор, когда люди начинают бросаться статистикой в ИТ. :-) И дело не в том, что честные результаты, слишком дороги в добывании и не очень лицеприятны, а потому "правильные" эксперименты редко когда проводятся. И даже не потому, что говоря об ошибках мы попадаем в туманную область между верификацией и и валидацией. Код - это не готовый продукт. Интересно само производство. Цифры же берут из некого "конечного" состояния. Наиболее правильная метафора софтописания - хоровое пение. Готовятся, готовятся, спели первый релиз, потом готовятся дальше, спели второй. И так далее. САП - это стандартные модули, которые великолепно работают, но, которые надо впихивать в отличающиеся от стандартных процессы. Чем больше специфики, тем интереснее. При этом есть САП старый (не модульный) и новый (гибкий, нацеленый на DSL и так далее). О втором отзывы такие, что не позволяют их цитировать. Может быть оно и созреет. Только я сомневаюсь. Тем более, некоторые утверждают, что Оракл скупил все перспективные фирмы в этой области. На практике в большинстве случаев сила абстрактного мышления у большинства спецов такая, что переход от DSL к машинным кодам надо делать максимально коротким, чтоб сократить количество уровней, в которых "нужно творчество". Мутность и запутаность - удел учёных, которым важно написать докторскую по новейшей системе, а не сделать что-то работающее. Потому и изобретаются и новые названия, и хитроумные решения простых задач. Короче говоря, признавая принципиальную возможность создания языковых рабочих мест и прочих чудес автоматизации, я всё-таки не считаю, что полезно давать в руки неспециалистов столь мощный и гибкий инструмент. И массы программистов поднимать на абстрактные уровни тоже не стоит.

1842 - Ada Lovelace writes the first program. She is hampered in her efforts by the minor inconvenience that she doesn't have any actual computers to run her code. Enterprise architects will later relearn her techniques in order to program in UML. http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html

2. JetBrains выпускает в мае (сейчас -- готова вторая бета под Apache лицензией) Meta Programming System (http://www.jetbrains.com/mps/index.html), да еще и (подробности и ссылки на статьи -- http://blogs.jetbrains.com/mps/, главный разработчик -- krlz, а насчет того, что Apache-лицензия сохранится для версии 1.0, так это пока непонятно). Сохранится до 1.0. 1.0, кстати, будет в ближайшее время выпущена.

Я так и думал, что до 1.0 сохранится (то есть времени еще чуть-чуть осталось), а вот для 1.0 уже не сохранится -- бизнес-модель JetBrains торговать софтом, а не сервисом. Про цену даже не спрашиваю, ее никто до момента выпуска еще не знает, даже в фирме-разработчике :) Еще интересно, почему проект FONC/COLA/STEP и т.д. (ну никак они не выберут имя!) не рассматривается обозревателями всех мастей как проект из той же языкоориентированной серии -- ведь там все то же самое, хотя и сделаны немного другие акценты. Один из интересных путей развития в данной предметной области -- это взять языковое ядро из этой COLA и повторить идеи качественной DSL-ориентированной IDE из MPS. Результат может быть интересен не только свободной лицензией, но и содержательно: Экстремальный подход демонстрирует Ian Piumarta 27 ноября 2007г. в списке рассылки FONC:

We should be able to go beyond even domain-specific languages, to what I've been calling 'mood-specific languages'. If it makes my (e.g.) message-passing code more readable to be able to write 'x[y,z]' instead of '(x at: y) at: z' during a three-line region of my program in the middle of some function or method, I want to be able to instantiate my new syntactic convention for just those three lines of code. It'll certainly not look anything like this...

`push-syntax expr += expr-1[expr-2,expr-3]
-> ((expr-1 at: expr-2) at: expr-3) ;

c[i,k] = a[i,j] * b[j,k].

`pop-syntax expr

but the closer we can get to the spirit of the above, the better.

Я так и думал, что до 1.0 сохранится (то есть времени еще чуть-чуть осталось), а вот для 1.0 уже не сохранится -- бизнес-модель JetBrains торговать софтом, а не сервисом. Про цену даже не спрашиваю, ее никто до момента выпуска еще не знает, даже в фирме-разработчике :) После 1.0 мы тоже будем опен сорсными. Хотя что-то мне смутно подсказывает, что подобные вещи можно делать и в MPS, ибо она написана на самой себе. Так?МПС вообще language agnostic. На нем можно реализовывать любые языки.

О! Вы делаете опенсорсный продукт! Я исправил текст в исходном постинге. В моих глазах у вашей разработки следующие достоинства по отношению к другим: а) опенсорс, что дает возможность экспериментировать и подключать разных людей б) интересные идеи по IDE, что дает шанс не просто экспериментировать, но и реально работать в) разработчики говорят не только по английски, но и по-русски (хотя это и субъективное достоинство ;) г) система (как я понял), написана на самой себе, что обычно дает нетривиальные возможности, недостижимые простыми методами в системах, написанных на других языках С language agnostic не все просто, ежели обратить внимание на динамические языки, с экстремально поздним связыванием (extreme late binding, типа того же smalltalk в отличие от Java). Ибо языки ведь определяются не чистым синтаксисом (другими словами, в языках важен не только "синтаксический сахар"). Так, важна еще и рефлексивность (для примера -- статья двадцатилетней давности http://www.laputan.org/ref89/ref89.html). Еще есть языки, где не хватает псевдографики (тут я не разобрался еще с вашим табличным редактором). Так, в презентации Intentional Software есть пример языка принципиальных электрических схем -- у вас такое можно? Вопрос не такой праздный, ибо одному нашему клиенту нужно делать стандартное представление языка и графический редактор для системы имитационного моделирования: там языков, подразумевающих что-то типа принципиальной схемы, чертежа или даже географической карты довольно много, и DSL-инструментарий для таких "нетьюринговых" языков был бы очень интересен. Если пойти в этой "языковости" в другую сторону, то упремся в AST как структуру представления знаний. Дальше пойдут вопросы об upper ontology, представимой этой моделью, способами ее пополнения, возможностью стыковки с людьми, для которых онтологический разговор главный и "онтологическая стыковка" разных DSL по типу ISO 15926 (тут мои мысли пока смутные, но я надеюсь их постепенно прояснить -- речь идет о специальных DSL моделирования данных, ибо люди матюкаются, но юзают OWL исключительно по причине отсутствия инструментария для других языков. Тут и может прийти на помощь языкомёт типа вашей MPS). То есть я верю, что MPS language-agnostic, но хорошо бы указать класс языков, для которых этот агностицизм выполняется :) Еще очень интересно, как к вам внутрь (или снаружи) можно вставить какой-нибудь оптимизатор кода (у меня много клиентов интересуются скоростью счета).

С language agnostic не все просто, ежели обратить внимание на динамические языки, с экстремально поздним связыванием (extreme late binding, типа того же smalltalk в отличие от Java). Ибо языки ведь определяются не чистым синтаксисом (другими словами, в языках важен не только "синтаксический сахар"). Так, важна еще и рефлексивность (для примера -- статья двадцатилетней давности http://www.laputan.org/ref89/ref89.html). Да нет, почему. Рефлексивность нужна во время выполнения, а не во время редактирования, тут в принципе мы роли не играем. Если что, у нас есть javascript, который определен в мпс. Если точнее насчет агностицизма, то больше всего мы работали с сильно типизированными языками. И их, естественно, лучше всего поддерживаем. Еще есть языки, где не хватает псевдографики (тут я не разобрался еще с вашим табличным редактором). Так, в презентации Intentional Software есть пример языка принципиальных электрических схем -- у вас такое можно? Вопрос не такой праздный, ибо одному нашему клиенту нужно делать стандартное представление языка и графический редактор для системы имитационного моделирования: там языков, подразумевающих что-то типа принципиальной схемы, чертежа или даже географической карты довольно много, и DSL-инструментарий для таких "нетьюринговых" языков был бы очень интересен. Мы эксперементировали с псевдографикой. У нас были химические формулы (мы делали интерпретатор пролога, и пробовали добавлять туда domain-specific-расширения. Если пойти в этой "языковости" в другую сторону, то упремся в AST как структуру представления знаний. Дальше пойдут вопросы об upper ontology, представимой этой моделью, способами ее пополнения, возможностью стыковки с людьми, для которых онтологический разговор главный и "онтологическая стыковка" разных DSL по типу ISO 15926 (тут мои мысли пока смутные, но я надеюсь их постепенно прояснить -- речь идет о специальных DSL моделирования данных, ибо люди матюкаются, но юзают OWL исключительно по причине отсутствия инструментария для других языков. Тут и может прийти на помощь языкомёт типа вашей MPS). У меня диплом был реализация редактора OWL на MPS. :-) Правда, все это уже давно заброшено. Еще очень интересно, как к вам внутрь (или снаружи) можно вставить какой-нибудь оптимизатор кода (у меня много клиентов интересуются скоростью счета). С оптимизацией мы много не эксперементировали, но сложные преобразования кода (а не просто замена высокоуровневого кода более низкоуровневым кодом), мы делали. Так что, вставить оптимизатор вполне возможно.

Хех, это и есть главный вопрос: у вас время выполнения и время редактирования как связаны. В разных IDE на этот вопрос отвечают по-разному (хороший пример тут, например, языки-среды smalltalk -- типа того же Squeak). Это я понял, что вы экспериментировали с псевдографикой. Но ежели вам нужно нарисовать схему детекторного приемника, а символа детектора и катушки в псевдографики нету? По-другому задам вопрос: генерация кода расчета электрической сети возможна, с сохранением удобного редактирования принципиальной схемы этой сети? А с учетом предыдущего абзаца -- расчет (опускаю "генерацию кода", зачем о ней знать пользователю) электрической сети возможен, перемежаемый редактированием этой сети в формате принципиальной схемы? В презентации Intentional Software есть слайд, который прямо отвечает на вопрос о возможности, как минимум, задания языка электрической принципиальной схемы. Насчет реализации OWL на MPS -- интересно именно с онтологической частью: вы семантическую сетку онтологии хранили отдельно, или использовали AST в качестве этой самой семантической сетки? Про оптимизацию тогда задам вопрос по-другому: а ежели речь идет о реализации суперкомпилятора (моя мысль тут была http://ailev.livejournal.com/565598.html, а про суперкомпиляторы -- http://ailev.livejournal.com/544965.html. Ах, какие там длинные треды ;)))

Хех, это и есть главный вопрос: у вас время выполнения и время редактирования как связаны. В разных IDE на этот вопрос отвечают по-разному (хороший пример тут, например, языки-среды smalltalk -- типа того же Squeak). У нас никак. За исключением языков для определения языков, которые генерятся в Java, компилируются, и перегружаются. Это я понял, что вы экспериментировали с псевдографикой. Но ежели вам нужно нарисовать схему детекторного приемника, а символа детектора и катушки в псевдографики нету? По-другому задам вопрос: генерация кода расчета электрической сети возможна, с сохранением удобного редактирования принципиальной схемы этой сети? А с учетом предыдущего абзаца -- расчет (опускаю "генерацию кода", зачем о ней знать пользователю) электрической сети возможен, перемежаемый редактированием этой сети в формате принципиальной схемы? В презентации Intentional Software есть слайд, который прямо отвечает на вопрос о возможности, как минимум, задания языка электрической принципиальной схемы. У нас для этого придется движок улучшать. Средствами языка для определения редактора это сейчас не сделать. Насчет реализации OWL на MPS -- интересно именно с онтологической частью: вы семантическую сетку онтологии хранили отдельно, или использовали AST в качестве этой самой семантической сетки? В смысле семантической сетки? У нас был редактор для OWL, но про семантику он немного знал, хотя везде был комплишен, навигация, итп. Про суперкомпиляцию где-то слышал, но подробностей не знаю. Почитаю завтра.

Я немного продолжил тему "обычные языки vs DSL" в конце постинга http://ailev.livejournal.com/685455.html -- и там еще интересный разговор в комментах получился с avlasov про тестирование программ, написанных на винегрете из DSL.