Обсуждение

Почему я этим всем занимаюсь? Я бы с удовольствием воспользовался готовым универсальным моделером, чтобы делать в нем DSL PraxOS в таких domain как системная инженерия, организационное управление и ситуационная инженерия методов. А дальше бы я применял эти DSL на практике, получал опыт, и выпускал бы новые версии этих языков. Но универсального моделера нетути, и приходится думать, сколько ждать до того момента, когда он появится "сам собой", или примериваться к тому, чтобы затеять его разработку. А чем Вас не устраивают internal DSL, которые уже отработаны и которые можно использовать прямо сейчас, без необходимости ждать когда сделают чудесный золотой моделлер? Такие языки как Lisp, Scala, Haskell, OCaml/F# позволяют стругать как internal DSL, так и быстро делать парсеры для external DSL (опять же использую специализированный DSL для парсеров).

А меня интересуют DSL=метамодели+нотации, которые парсятся в "богатую" отчуждаемую и доступную другим моделерам=САПР модель. Эта модель, я думаю, должна быть выражена в терминах ISO 15926-2 (который, кстати, выразим и в first order logic, и в виде RDF). Эта парадигма моделирования-программирования очень похожа на Ecore, KM3, MOF, только сильно побогаче. А потом там вообще уходит в логическую сторону. Далее: когда говорится об IDE, то мне представляется не UML-редактор или Java-среда, а лихой машиностроительный САПР с 3D-интерфейсом. Мы с vvagr наблюдали тарелочки Dassault Systemes с полномасштабным самолетом, а также иерархией моделей типа UML, представленных "объемными" табличками. Это все работало и жужжало, так что я знаю о существовании таких решений. Что не нравится в Dassault Systemes, чтобы это был "универсальный моделер": -- страшно дорого, даже для того, чтобы попробовать. Система закрытая. -- нет надлежащего инструментария до пополнения числа DSL (может, и есть, но это тайна покрытая мраком), а инструментарий этот, похоже, пишется "руками", а не являет собой language workbench. А все остальное там хорошо -- но как же оно не походит на все эти Haskell, OCaml/F# и т.д.. У меня в голове просто модель -- это какая-нибудь (виденная мной в той же DS V6) подлодка, у которой 4-6млн.деталей, каждая из которых описана в десятке разных DSL (редакторы которых открывались в самых разных приложениях, а результат был слит в единое целое -- и там даже шло имитационное моделирование и прочий счет), и все эти детали перевязаны сложными отношениями, по поводу которых тоже работали разные DSL. А потом пошли трансформации моделей (например, порождается код контроллера на C по его архитектуре, или код для станка с числовым управлением) -- и все это задорого можно купить уже сегодня. И это совсем не похоже на Haskell или F#, на которых я решу одну десятую часть вопросов одной сотой части нужных мне аспектов моделирования системы.

Эта презентация намекает, что возможно менять метамодель так, чтобы при этом отслеживать сохранение целостности уже созданных моделей. Пока это rocket science, но через пять лет это будет сидеть где-нибудь глубоко внутри модельного-программного инструментария. Этот дядько сам же пишет вычисление difference of metamodels, что это очень сложно. Вообще говоря, тут возникают задачи, которые сложнее чем NP-полные задачи :). Ибо надо сравнивать выражения, которые содержат функции в качестве параметров. Вобщем, задача сродни создания суперкомпилятора (проект по созданию джавовского суперкомпилятора загнулся). Я подобными задачами озабачивался для целей рефакторинга. Ну для примитивных случаев конечно можно сделать решение. Но в поисках практичных решений, вскоре моя мысля прибежала в abstract interpretation и верификацию, т.е. это пока самый простой способ (при том что это все очень сложно).

Что касается повторения функциональности Dassault Systems в опен сорс виде - то это по любому, такая куча работы, в которой ДСЛ дай бог 1% займет. Теоретически ведь можно взять опен-сорс 3Д моделлеры, скрестить с опен-сорс УМЛ-моделлерами и опен-сорс кодогенераторами и прочим. Но это все не будет работать с 4-6 млн деталей. Потому как масштабируемый софт совсем по другому пишется, нежели обычный. А на Хаскелле можно генерить в том числе и САПР модели, если знать целевой формат.

А ведь верно, похоже на суперкомпиляцию чем-то. Нужно бы указать на эту работу суперкомпиляторщикам. Мне тут на днях в очередной раз рассказали (и я затем пересказал это собственными словами в http://ailev.livejournal.com/755822.html на примере стека приложений ISO 15926), что самое сложное обычно лежит глубоко внизу, создается двумя-тремя человеками из какой-то лаборатории, а затем юзается миллионами людей, работающими на три-четыре уровня инструментария выше. И нормально, так все современные технологии устроены. Нужно только определиться, на каком уровне стека ты хочешь/можешь работать. Я хочу работать, создавая DSL -- я онтолог-когнитолог, организационный архитектор, исследователь методов и паттернов работы и т.д. У меня нет инструмента, поэтому я и озабочен его созданием. Конечно, мне самому не написать суперкомпилятор DSL. Но вот использовать его я вполне готов -- было бы кому его сделать ;)

Нет, я тут вполне согласен с той точкой зрения, что сегодняшний опен сорс -- это зачастую такой же отстой, как Майкрософтовский софт, только бесплатный. Если бы я повторял функциональность Dassault Systemes (что, IMHO, с некоторыми оговорками вполне осмысленная задача), то я бы ни за что не скрещивал уже имеющийся и написанный софт. Я бы именно что писал заново (хотя сама Dassault Systemes просто скупала удачные разработки и объединяла их в одно целое). Это нужно отдельно обсуждать, как можно было бы все это написать, не теряя свойство масштабируемости, и тут меня вдохновляет vpri.org (они публикуют и публикуют кратенькие отчеты, показывающие, как можно упрощать софтовые решения в разы и разы, если применить голову).

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

Я Вам как-то подкидывал ссылку на http://www.impredicative.com/ur/ - стартап нового толка, который делает язык для программирования Веба. Точнее, там один программер, он делает язык Ur, который типа идеальный хост для создания ДСЛей (and the Ur programming language is meant to be the ultimate host for embedded domain-specific languages). А Ur/Web - это конкретный ДСЛ для веб приложений, причем он позволяет избегать кучи проблем в этой сфере. В принципе, его можно адаптировать и для онтологий. Потому как он основан на row types. Грубо говоря, на табличках. Т.е. на факт-ориентированных запиях :). При этом у него хитрый компилятор, который последовательно упрощает программу от higher-order фич (во-многом в суперкомпиляторном стиле).

Да, это изменит мир. Зайти на сайт (или программа на компе, или они тогда уже сольются в одно), набросать какой-нибудь агрегат, покрутить в 3д, нажать "изготовить", и он где-то будет автоматом собран. Вообще, всё что угодно, от кулинарных блюд, до автомобилей (можно будет иметь такое хобби - временами рисовать себе машинку на своём пк, чтобы потом однажды нажать "изготовить"). Или даже домашних животных - тип(рыбка, зверёк, или диназаврик), форма, цвет, пушистость, громкость, черты характера. Нарисовать всё это, запустить модель, посмотреть как бегает, гавкает-мяукает, нажать "изготовить". Эта "модель" будет скомпилирована в точную инженерную документацию, полностью хранящуюся в молекуле нуклеиновой кислоты. Последняя будет помещена в заготовку яйцеклетки, а она будет помещена в специнкубатор. Через время домашний питомец будет готов. Ну или, в первую очередь, конечно, например, бык-производитель, телята которого будут набирать по 100кг качественного мяса за день. Этож все современные концепции "товара" смысл потеряют. Зато появятся новые - "товар" как "модель товара". - Каждая мельчайшая деталь этого автомобиля продумана до мелочей лучшими специалистами. Скачайте этот автомобиль на нашем сайте всего за... - У нас самые пушистые и ласковые домашние питомцы. Лучший подарок детям! Новогодние скидки! Выберите и скачайте на нашем сайте всего за... ...

А пришлите мне письмо, я вам кое-какие материалы отправлю.

Это нужно отдельно обсуждать, как можно было бы все это написать, не теряя свойство масштабируемости, и тут меня вдохновляет vpri.org (они публикуют и публикуют кратенькие отчеты, показывающие, как можно упрощать софтовые решения в разы и разы, если применить голову). Тут есть такой аспект, что упрощение софта разы, одновременно повышает сложность его тестирования. Т.е. как бы, инспекция человеком, конечно проходит проще. Ну и теоретически код содержит меньше багов. Но есть проблема, что один баг может откликнутся в бОльшем кол-ве мест. И это все становится менее предсказуемым. Ибо баг может стать видимым только в одном случая, а в остальных остаться в латентной форме. Поэтому простое тестирование его не выявляет. Это одна из причин почему слабо развивается такая, на первый взгляд, мощная и легковесная вещь как аспект-ориентированное программирование.

прислал (на ailev ... su)

Мне кажется, что дело не в тестировании, а в особых поворотах мозгов, требующихся для аспект-ориентированной, функциональной или логической работы. Объект-ориентированная работа по сравнению с "народной" онтологией (folk ontology) имеет минимальную трудность в обучении -- хотя как только речь идет об "истинной объект-ориентированности" типа смоллтоковской, то начинаются те же траблы и малое распространение. Насчет багов -- это особый разговор, совершенно другой аспект проблемы. Все эти споры насчет статической и динамической типизации тоже про баги, но спор ведь выглядит совершенно религиозным. У меня просто есть подозрение: если компиляция близка к однопроходной (фрагмент текста исходного кода во фрагмент текста на ассемблере), то такие языки популярны. А если более сложное преобразование, типа суперкомпиляции, то такие языки непопулярны ибо требуют в ходе написания заворота мозгов для понимания, что с этим кодом будет происходить дальше. И дело не в бОльшем числе мест, а в понятном без тренинга мозгов преобразовании. Что с этим делать, я не знаю -- но серьезные программы все чаще и чаще пишут на таких "с трудом понимаемых" языках, ибо на легкопонимаемых языках эти программы, похоже, вообще не пишутся ввиду огромного объема, а когда пишутся, то из-за их необозримости и огромного числа участников написания становятся неподъемными. Но это все тоже домыслы, статистики никто не ведет, да и статистика тут как инструмент тоже неправильна.

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

\\ Но вот использовать его я вполне готов -- было бы кому его сделать ;) Хм. А почему бы вам не попробовать связатся с разработчиками уже готовой такой системы, с language workbench? Я имею в виду Intentional Software Corporation http://intentsoft.com/company/contact.html У них какраз сейчас идет фаза бета-тестирования. Да и подход к работе с пользователями довольно закрытый, типа как у Гугла. С индивидуальными пользователями не работают, а вот с организациями... Я пробовал как-то общатся. Конечно пока на уровне 3Д у них ничего нет, только показывали пример с электрическими схемами. Но это ведь пока.

Например можно на Magnus Christerson Vice President, Product Management and Marketing Ph: +1 425 822 0700 Email: magnus@intentsoft.com выйти. Я с ним общался. Он у них за внешние связи отвечает, как я понимаю.

Там ведь закрытая система, намучаешься организационно с улаживанием сложных отношений между ими, нами, разработчиками конкретных DSL, заказчиками на эти DSL плюс пришивание к конкретным САПР (ибо разработать всю линейку инженерных DSL с нуля практически невозможно). Хотя я видел скриншоты с моделью их электрической схемы. Убедительно.

\\ разработчиками конкретных DSL, заказчиками на эти DSL плюс пришивание к конкретным САПР вообще-то система их предполагает что DSLи разрабатывают сами прикладники, исходя из собственных представлений вы смотрели видео с конференции? http://download.microsoft.com/download/E/7/7/E77A8FCE-0362-4930-BD5E- 8A21EC77E38D/MagnusChristersonShaneClifford.MP4 там какраз об этом говорится конечно некоторая поддержка программистов все равно нужна но она уже именно технического плана, типа ОЛЕ в вордовских документах, о внедрении и поддержке разнородных объектов что же касается проблемной области -- тут сами эксперты в этих проблемных областях и занимаются \\ Там ведь закрытая система так в том то и дело, что подобный продукт не выпустиш в виде коробочной версии потому распространяют они её только в тестовом варианте, чтобы иметь сильную обратную связь с теми кто её использует и нарабатывать базу прикладных решений потому к ним сейчас можно просто подойти и спросить, и если убедиш в нужности тебе их системы, то и взять её использовать вполне бесплатно.

Подумаем. У нас все-таки использование не для себя, а для самых разных ситуаций у клиентов -- тут может быть очень сложно договориться.

Интересный пост, но каждый раз читаю вас по этой теме и пытаюсь представить как оно должно выглядеть в металле :) и нечего не получается :(. Слишком абстрактно написано и сложно представить как собственно работать с этим чудо моделером. У меня честно говоря складывается впечатление что вы сами не до конца представляете как должен выглядеть инструмент который вас бы устроил. Вы не могли бы написать что то типа user-store работы с таким инструментом. Например мы хотим сделать что-то ... открываем наш инструмент на экране видим ... нажимаем ... выбираем ... вводим ... в результате на выходе получаем ... Я думаю такой текст будет интересен не только мне но и вам т.к. поможет собрать многие вещи в кучу.