Обсуждение

Мне тоже больше импонирует подход "IDE для DSL". Потому как первые два уже явно не соответствуют текущему пониманию дел. Правда опять есть риск что оно все устареет на момент реализации.

Такой чудо софт будет не продать. По крайней мере массово.

Продать можно все полезное. Если этот чудо-софт субъективно (а "объективно" полезности не бывает ;) полезен не меньше, чем затраты на его создание и развитие, то его вполне можно продать. Весь вопрос в бизнес-модели. Софт, конечно, должен быть свободным -- и даже не SaaS. А продавать нужно услуги по его освоению (вернее, не его освоению, а освоению предметов, в нем отмоделированных) и помощь в настройке на конкретные условия.

Михаил Донской регулярно сетовал, что работы программистов недолговечны -- десяток лет с начала проекта, и любой софт можно выкидывать в утиль. Сохраняется только опыт. Я думаю, что через пять лет (на момент реализации) только-только появится понимание важности и нужности такого софта. Тут нужно заметить, что OMG перешла на стандартизацию моделей вместо стандартизации интерфейсов в том числе и потому, что модели более живучи, чем интерфейсы: меняется софт, а модели остаются, перереализовываясь в новом софте. А потом придет сингулярность и съест и софт, и модели ;)

Маркетинг софта во многом основан на поддержке стандартов "для которых легко найти книги, курсы и дешёвых специалистов"

avlasov навел на интересную мысль: софт и нужно разрабатывать как стандарт. MDA являет собой промежуточный вариант: стандарты метамоделей по сути являются чем-то средним между стандартом-предметом и стандартом-софтом (ибо метамодели на UML2 в какой-то мере являются исполнимыми, т.е. представляют собой софт). Вот эту линию и нужно додавить до конца.

метамодели на UML2 являются исполнимыми в той мере, в которой поддерживают Шлейер-Меллор :-) Меллор action language для UML2 создавал.

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

xUML - это все-таки не картинки, а полная отладка софта на уровне моделирования. Плюс компиляторы из моделей, эффективность которых и является основной проблемой для тула. То есть, дизайнеры-модельщики есть, а программистов нет.

Кстати, логика еще более жывучая, основные математические и логические концепции сотни лет не меняются :) Хотя тут тоже есть свои стандарты, тонкости и пр.

Кстати насчет DSL. Сейчас уже более менее зрело программирование с dependent types. Депендент тайп - типа параметризованные выражениями, например массив четных числе или массив длины 5. Фактически, депендент тайпс позволяют задавать спецификации, и явно или неявно доказывать их корректность - путем написания функции которая преобразует тип одновременно с функцией, которая преобразует входные данные. А затем компилятор проверяет валидность преобразования. Фактически неявно доказывается соответствие программы спецификации (выраженной типом). Эти языки пока новы, но их уже штук 5 минимум. Дык вот, есть такой язык/формальная система - Coq. Это система ХОЛ, поддерживающая депендент тайпс. Она весьма зрелая (на ней написали уже верифицированный компилятор подмножества Си, а один парнище пишет книгу, где убеждает что верифицированное программирование уже зрелая технология). Из программ/доказательств на этом языке, можно генерить Хаскел и МЛ код. А в Хаскел и МЛ языках есть библиотеки парсер комбинаторов - что-то типа ОМета (точнее, ОМета - это что-то вроде библиотеки парсер комбинаторов). В результате, получается что этот Coq - готовое йазыковое капище, ибо: 1 лексинг/парсинг можно вести в Хаскел/МЛ, там это легко и элегантно описывается (как в ОМета) 2 АСТ легко задается системой типов Хёдли-Милнера, которая лежит в основе Хаскел/МЛ типов 3 в Coq можно описывать преобразования из различных АСТ, задавать семантики языков, доказывать корректность и т.д. Сложности с верификацией в значительной степени облегчаются системой депендент тайпс плюс специализированными верификационным тактиками. 4 можно задавать и императивные фичи. В Хаскеле это делается монадами, которые хорошо разработаны. Монада - это такой способ инкапсуляции состояния и встраивания его в чистый функциональный язык. Для Coq есть библиотека работы с императивными монадами. 5 чистый функциональный язык типа Хаскела довольно просто кладется на многоядерность, ибо там порядок вычислений не важен, следовательно, подвыражения можно вычислять параллельно. Вобщем, компьютерная революция похоже началась и я ее немного проспал :). Хотя с Coq знаком с 2001 года.

Компьютерная революция еще не началась. Но явно зреет революционная ситуация: отдельные детальки начинают встречаться то тут, то там -- а полная сборка из деталек происходит пока только в блогах типа наших, университетских курилках и (по очень отдельным частям) в тех же университетских проектах. Как я понимаю, все эти 5 пунктов про Coq -- это пока только сослагательное наклонение, хотя много кода уже написано. Но и система Пиумарты уже содержит много кода, и тоже вся в сослагательном наклонении. Но одни и те же тренды в основанных на разных парадигмах ветвях компиляторщиков уже видны, это факт: -- унифицированное рассмотрение динамической и статической типизации, подвод под доказательство программ "сверхпозднего связывания", рефлексия и прочие неразличения интерпретации и компиляции -- выход в мультипарадигмальность -- стек языков, с DSL на верхушке, "языкоориентированность" и прочая "языковая" расширяемость (по этой линии проходит и MDA) -- формальные модели в основании всех базовых языков, "поэзия" типа С и Perl уже не проходит -- язык, совмещенный с IDE и неотделимый от нее (идея еще со Smalltalk) ... и так далее В какой-то момент пойдут сборки всех этих идей в рамках инструментальных систем. А вот когда начнутся на верхушках этих систем реализовываться прикладные системы, а на низушках -- другие процессорные архитектуры (выгадывая 100 раз минимально на скорости работы в сложных задачах) тогда и случится эта самая революция. Но революционность к этому моменту уже никто не будет замечать...

Как я понимаю, все эти 5 пунктов про Coq -- это пока только сослагательное наклонение, хотя много кода уже написано. Но и система Пиумарты уже содержит много кода, и тоже вся в сослагательном наклонении. Не сослагательное. Более точно: 1. библиотеки парсеров зрелые и давно существуют. ОКамловские используются в реальных проектах точно. 2. системы типов в Хаскел/МЛ рабочие. Это вполне зрелые языки. Так что АСТ реализуется на них легко. 3. Coq как система верифкации - зрелая по факту того, что верифицировали реальный компилятор Си. И книгу пишут. 4. Императивная библиотечка пока незрелая. Но дело в том, что императивности в моделях лучше избегать как черта лысого. 5. Хаскел реально гоняется на многоядерных системах, не так давно сделали. Но это опять-таки задел на будущее. На текущий момент в йазыковых капищах это нахрен не нужно, но на перспективу задел есть хороший. Уже есть стартап несущий депендент типы в массы http://www.impredicative.com/ur/ Там разумеется есть много проблем, но это не проблема для стартап деятельности, а как раз наоборот - стартап ведь и призван решить какую-то проблему. Я к тому что фундаментальные подходы готовы и тулзы есть, пора заниматься внедрением в обычную жизнь. Я вот сейчас серьезно задумываюсь о создании инструментария для парсенья Жабы (каких-то подмножеств), чтобы можно было автоматически верифицировать/тестировать на простые баги. Такие инструментарии есть, но они промышленно не юзабельны, ибо: 1. не поддерживают Жабу 1.5 2. нет автомтических детекторов инвариантов (что означает проблемы с циклами) 3. Жабные библиотеки не специфицрованы формально Первый пункт решить несложно - по крайней мере, надо чтобы входной код разбирался, пусть без формальных выводов. Второй пункт сложнее, но я тут буду думать как Coq применять, похоже там можно найти полу-автоматическое решение. Третий пункт - вопрос времени, если предыдущие два решить, то формализации библиотек можно потихоньку наращивать.

Компьютерная революция еще не началась. Но явно зреет революционная ситуация: отдельные детальки начинают встречаться то тут, то там -- а полная сборка из деталек происходит пока только в блогах типа наших, университетских курилках и (по очень отдельным частям) в тех же университетских проектах. Она не началась для стороннего зрителя, а я вот чувствую себя компьютерным Лениным, который срочно ищет компьютерный броневичок :).

И тут я замечу, что суперкомпилятор для Рефала сделали, а для Явы (почему-то) обломались -- долго было "вот-вот сделаем", а потом все скисло. Это сильно настораживает, ибо задачка то того же класса сложности.

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