Обсуждение

Основная задача OMG - объединить тулы различных производителей. Для этого и нужно мета-мета-мета-мета. Да и полное описание системы дают только машины состояний. Хотя, во многих случаях можно жить и с дырами. И я бы ждал версии 1.1

Объединить не тулы различных производителей, а различные view, сделанные с различных viewpoints -- эта задача стоит и перед одним производителем. Эта же задача может быть переформулирована как объединение многих DSL в одной IDE. Эта же задача формулируется как комплексное имитационное моделирование -- объединение в рамках одного исполнения множества разнородных моделей. Один из выводов, который делают все эти разные группы людей -- это необходимость иметь общую онтологическую подложку, чтобы все разные языки в конечном итоге получались из одного мета-мета-мета корня. Так что с мета-мета-мета все ОК как с принципом. Мне непонятно, почему об этом так запутанно и неэлегантно говорят. Или это запутанно и неэлегантно только для меня, тёмного и неграмотного? Но у меня есть впечатление, что эта навороченность проявляется из-за того, что в основе своей выбрано атрибутное представление, и перескок с уровня на уровень представляет собой некоторую проблему. Эволюция там та же, что и была в обычных языках программирования. Так, composition у них появилось только во 2й версии, а до этого пакетов не было. Т.е. теперь это что-то типа ADA и Modula. А ведь все это нынешнее засилье ООП пошло от языков, которые были придуманы задолго до "пакетных" ADA и Modula. Так что я бы ожидал каких-то переформулирований в этой области, и эти переформулирования, скорее всего, будут относиться к мультипарадигмальности представления (ну, или хотя бы смены парадигмы, например на факт-ориентированное представление типа ORM -- это ведь по факту произошло с SBVR). Полное описание [процессов] дают не только машины состояний. Я приводил тут ссылки (там очень много материалов на странице Conrad Bock, http://ailev.livejournal.com/689613.html), которые разъясняют формализм полного описания в BPMN 2 (а сейчас такая полнота гарантируется BPDM, но графически выражается в нем только оркестровка, хореография остается на уровне абстрактного синтаксиса). К вопросу об ожидании какой-то версии чего-то важного: лучше не ожидать, лучше участвовать. :)

OMG - это всё-таки союз производителей тулов. Потому сначала собирают кучу, а потом начинают искать корни. Языки программирования развиваются нелинейно. Можно вспомнить тот же SmallTalk или отличия С++ от Objective C. Или сравнить Oberon 2 c Java. Не говоря уже о линии Lisp. Называть это эволюцией я бы не стал. Я так подозреваю, состав комиссии гораздо важнее, чем теоретические воззрения.

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