В конце сентября я привел пример технологического стека (
http://ailev.livejournal.com/620564.html), некоторой виртуальной "вертикальной интеграции", в которой может существовать бесчисленное множество ответвлений:Память MRAM (
http://www.mram-info.com/)
Процессор "неконвенциональной архитектруры", аппаратно поддерживающий виртуальную машину COLA и работающий с памятью MRAM -- (
http://vpri.org/html/work/ifnct.htm).
Среда мультипарадигмального (функционального, объектного, аспектного, DSL и т.д.) программирования на COLA -- (
http://www.vpri.org/vp_wiki)
Крокет, как распределенная мультипарадигмальная операционная среда, обеспечивающая коллаборацию. (
http://opencroquet.org)
Онтологическая "шина приложений" -- Gellish и протоколы обмена информацией между приложениями (включая Gellish-запросы) -- (
http://gellish.wiki.sourceforge.net/).
Набор приложений с "фасадами" для "шины приложений" Gellish
-- управление вариантами (family engineering) и распределенное хранение версий информационной модели системы/проекта (типа git) с нотаризацией -- синхронизация работ и учет продукционных и координационных фактов: кто что кому когда обещал, кто что кому когда publish сделанного. Протоколы и структуры данных, независимый нотариат.
-- порождающий дизайн (САПРы конструкторские и проектировщиков), включая программы симуляции.
-- организационное моделирование для проекта расширенной организации
-- ресурсы/логистика и финансы для проекта расширенной организации, включая эксплуатацию
-- надежность и риски (ремонты по состояниям) при эксплуатации
-- courseware (документация, задачи, последовательность освоения и т.д. -- не софт, ибо софт уже есть: каждое предметное приложение является еще и учебным софтом, хотя на нем можно решать и заведомо неучебные, т.е. исследовательские и инженерные задачи).
Термоядерная электростанция, сделанная и эксплуатируемая при помощи указанного набора приложений (по факту ITER сейчас использует ISO 15288).
Впрочем, все эти технологии приведены только как примеры -- и при необходимости могут быть заменены другими (так, онтология Gellish вполне может быть заменена какой-нибудь другой, прежде всего ISO 15926 -- хотя это все и плохого качества онтологии. Для такого дела можно и "с нуля" онтологию сделать -- или выпустить апгрейд уже существующих). И так со всеми этими слоями.
Весь вопрос в том, что в реальности эти все технологии могут быть сами по себе разработаны, но совершенно необязательно выстроятся в стек. Фактически, в (пока абсолютно непромышленный) стек могут быть выстроены только COLA и Croquet, ибо в них обоих заводилой Алан Кей и у Крокета прописаны уже планы в будущем сесть на Колу. Но даже процессорные планы COLA, хотя и подразумевают неконвенциональную архитектуру разрабатываемого ими железа (опять же -- спасибо Алану Кею), не включают в себя изменения архитектуры, связанные с использованием MRAM. Даже САПР в Крокете появился, но это явно не мощный промышленный онтологический САПР, который должен бы быть в данном стеке.
Пофантазируем, что нужно сделать, чтобы такой стек получился (помня при этом, что можно добиться всего чего угодно, если необязательно чтобы лавры принадлежали именно тебе):
1. Решить нерешаемые политические задачи и получить много-много государственных денег на "прорывные НИОКР", затем бездарно их потратить на то, чтобы такой стек получился (законтрактовать все команды на то, чтобы они прицелились друг во друга -- с учетом того, что значительной части команд вообще еще нет, а во многих других случаях речь идет не о командах, а о не пойми чем). По факту, все эти деньги ученые пустят на много-много интереснейших "боковых побегов" для их любимых технологий, но меньше всего на обеспечение вертикального стеыка технологий. Утопия от начала и до конца.
2. Писать прочувствованные письма командам, занимающимся различными слоями стека, чтобы они обратили внимание друг на друга, и договорились. Лично ездить и уговаривать. Разработать презентации, писать статьи с разъяснением взаимной пользы смежных технологий, чтобы поисковые технологии тыкали их со всех экранов в необходимость обратить внимание друг на друга. В общем, поработать свахой. С примерно той же вероятностью результата, что и у обычной свахи. Беда в том, что женихи не имеют плотных очертаний (многих так вообще нет), а также не имеют собственных ресурсов, чтобы вести необходимые работы -- даже если они почему-то и будут друг другом очарованы.
3. Подружиться с венчурным капиталистом и сделать много-много связанных стартапов -- но венчурным капиталистам не нужны взаимные риски всех этих стартапов, им и "прорывность" не слишком нужна, а нужна массовость рынка. Тут же массовостью рынка не пахнет. Насколько я знаю, все крутые САПР и средства их интеграции были сделаны под совершенно конкретные заказы совершенно конкретных крупных фирм, которым нужно было много дизайнить. И уж точно для таких проектов принято выбирать "общепринятые средства разработки", а не "прорывные" (грубо говоря, писать на Java а не Haskell, и уж точно не на COLA).
4. Внедриться в какой-нибудь ВУЗ (например, я знаю, что мой блог читают люди из МИФИ -- почему бы и не туда?), сделать учебные проекты на соответствующих кафедрах -- ибо где еще можно встретить такой зоопарк разных тематик, как не в ВУЗе? Жесткими административными методами потребовать этим проектам сотрудничать друг с другом. Дальше решать задачу, как учебный проект довести до характеристик промышленного. По мере накопления опыта выпускниками и профессорами переходить к стратегии по п.3.
5. Продолжите, плиз, в комментах. Мне интересно.