Стратегия создания платформы языкоориентированного онтологического программирования .15926
Текущее поколение универсальных моделеров известно под разными именами, хотя делают они абсолютно одно и то же:
-- modeling tool siut, ибо в них внутре UML (modeling language!), и это просто инструментарий (Artisan Software, MagcDraw и далее по всему списку).
-- ontology/semantic engineering/modeling platform/environent (http://www.neon-project.org, http://topquadrant.com/products/TB_Composer.html), если там внутри OWL/RDF и SPARQL и "онтологический" сленг.
-- data manager и/или data repository (http://www.epmtech.jotne.com/products.41332.en.html, http://www.noumenon.org.uk/category.php?id=NQ== ), если внутри EXPRESS и онтологии типа ISO 15926. ISO 12006, протоколы ISO 10303 и речь идет о производственных данных.
-- странные небольшие решения типа Relatics/Gellish (семантический спредшит, как они себя называют -- http://www.relatics.com/Home/VideoErvaringenRelaticsGebruiker.aspx, а на деле что-то типа PLM общего вида для неинженерного документооборота), ОргМастер (с неизвестным науке языком внутри -- ),
-- современные NoSQL базы данных с кучерявыми средствами , которые определяют свой "язык моделирования информации" и "язык запросов". Их число растет, и к ним стремительно будут появляться "редакторы общего вида", "генераторы приложений" и прочая обвязка. Главное, они с самого начала ориентированы на "кучерявые" схемы данных, но обсуждают их в графовом языке. Именно отсюда растет Simantics как онтологическая платформа (https://www.simantics.org/simantics/documents/DoctoralThesis_Hannu_Niemisto.pdf -- базовый труд называется Locality and order-invariant logic). Как ни странно, но системы поставщиков современных PLM (Aveva, Bentley и т.д.) помещаются именно в эту категорию: там у них весьма навороченные движки, которые даже не притворяются чем-то онтологическим. А затем сверху густо намазана "схема", уж какая кому понравится (например, Bentley понравилось в ProjectWise использовать ISO15926).
Все эти промышленные моделеры делают одно и то же: выражают в терминах UML, или OWL/RDF, или EXPRESS (а на самом деле -- в терминах внутреннего какого-то нам неизвестного представления, которое может существенно отличаться от этих языков, а только экспортироваться/импортироваться в привычном для всех виде) разные большие или небольшие онтологии (с существующей внешней/глобальной RDL или без таковой, а разрабатываемой тут же на коленке) -- и затем дающие средства для редактирования этих онтологий "на базовом языке" или сразу средства редактирования соответствующих "моделям данных" (онтологиям же) данных в спецредакторах текстовых, табличных или графических DSL.
Хуже всего было бы ценой неимоверных усилий и напряжения мысли изобрести уже изобретенный кем-то велосипед, и тем самым повторить какую-то из уже имеющихся систем. Не нужно повторять ENOVIA, все равно ресурсов не хватит ее повторить. Нужно круто обогнать, чтобы у нас учились и нас печатали в учебниках как пионеров новых подходов.
Чем соревнуются между собой все эти абсолютно одинаковые по духу, виду, вкусу и запаху решения?!
1. Ценой. Хотя ситуация тут быстро меняется (взять хотя бы тот же Simantics, или NeOn -- ценовые модели бывают разные), и цена смещается с цены самого софта на цену получения на нем собственного решения. Цена получения прикладного решения зависит прежде всего от скорости его программирования. То есть задача получения дешевой платформы программирования/моделирования/онтологизирования превращается в задачу получения платформы дешевого программирования/моделирования/онтологизирования. Важно не то, сколько стоит IDE, а сколько ты будешь осваивать эту IDE, а затем с какой скоростью на ней сможешь работать.
2. Поскольку все эти системы предназначены для "моделирования всего на свете", то соревнуются интерфейсом моделирования -- он во многом влияет на скорость работы (сравните скорость редактирования в командном редакторе текстов и WYSIWYG. Я редактировал в командном редакторе! Это не лучший мой опыт). Хотя на вкус и цвет в этих интерфейсах товарища нет (кто любит тексты, кто графику, а кто сам не знает, чего хочет), некоторые интерфейсы убеждают, что в них моделировать быстрее и эээ... эстетичнее. Синтаксический/графический сахар имеет значение. Тут можно еще добавить, что речь идет об интерфейсе "для человека" и его программировании, а не программировании языкового экспорта/импорта/запросов. Об этом следующий пункт:
3. Легкостью программированя языковых трансоформаций (а также, по сопряженности, генерации "отчетов любого вида"). Либо у вас тут есть спецстредства в виде какого-то супер-пупер DSL, либо вам предлагают "писать на Java или любом другом языке программирования", обеспечивая "удобный доступ к данным", а там уж как сами справитесь. Поэтому моделеры делятся на "удобные для программирования адапторов данных" и "поддерживается большое число адапторов данных, входных и выходных языков и интерфейсов программирования". Понятно, что длина списка тут не имеет значения, но ежели у вас руководство по программированию "адаптера" составляет пару томов мелким шрифтом, то вряд ли ваша система будет лидером в этом соревновании -- как и система, где никакого руководства нет, а есть лишь "база данных и доступ в нее из языка программирования").
4. Языки моделирования с одной стороны не имеют значения, а с другой -- имеют значение. Если у вас UML со стереотипами, то у вас одни удобства. Если OWL 2, то совсем другие. Если фреймовый логический язык, или графовый из серии NoSQL экспериментов, или какой-нибудь незнаемой теории гибрид, то вы либо будете легко программировать вашу онтологию, либо не очень.
Но в принципе, это не самое важное место. Обычно заявляется, что "принимаем и отдаем любой язык", а дальше соревнование идет по переводу потенциального "любой" в актуальное (число реализованных адаптеров).
5. Вообще, число "адаптеров" к разным представлениям данных и другим системам. Программисты всегда делают заявления, что "система позволяет выразить любую информацию и обеспечить ее трансформацию в любое другое представление". Тут никакого соревнования нет, весь вопрос в том, выполнено ли уже программирование (иногда сводящееся к полной переписке всей системы с заменой базового представления данных) для интересующих вас языков, или не выполнено.
6. Временем оборота. Например, Intergraph SPF после каждого изменения схемы нужно перегружать, а вот Dassault Systemes ENOVIA V6 может и не перегружаться и меняться "на лету".
7. Масштабируемостью, что можно условно назвать и как "скоростью работы" (даже с условием того, что схема не меняется и все работает "как в обычных базах данных"). Если грузануть в такую систему подводную лодку или атомную станцию (примерно 4.5млн. индивидуальных деталей), то система либо еще будет работать, либо просто остановится.
8. Коллаборативность. Если пятеро человек начнут редактировать одну и ту же схему, что у них получится? Это самое непростое место, ибо это требует сложных архитектурных решений, повышенной отказоустойчивости, организации всевозможных хитрых API, существенно влияет на скорость работы, заставляет задумываться над разными моделями обеспечения прав доступа и т.д.
В исследованиях по маркетингу неоднократно было описано, что "вторая во всех категориях система не побеждает на рынке", нужно заранее выбрать, в чем стать лучшим, а в чем -- средним или даже чем пожертвовать и стать худшим.
В тех же исследованиях по маркетингу написано, что от знаменитых конкурентов к неизвестному вам перейдут в тот момент, когда ваш продукт будет по показателям не менее чем на 30% лучше (что бы это ни значило). Это означает, что побеждать придется не "по очкам" (тем более, что "по очкам" победить денег на разработку никаких не хватит), а принципиальными отличиями, и хотелось бы понять -- какими.
Какие есть варианты "принципиальной победы" в .15926 над всеми конкурентами? Что дает считать, что проект не пытается повторить то, что давно сделали (или вот-вот сделают) конкуренты, а делает что-то такое, что потом эти конкуренты все будут повторять?
Вот мои гипотезы:
1. Внутри существенно используются онтологические особенности ISO 15926. Как ни странно, но это "модель мира", а не просто "схема данных". Это на EXPRESS или F-logic схема данных, а на ISO 15926 модель мира. Поэтому:
-- можно ожидать, что программирование с использованием 15926-типов будет более осмысленным с точки зрения отношения к реальности. Это означает, что будет меньше ошибок программирования принципиально другого типа. Это означает, что можно делать не только "формальный" контроль типов, но и в какой-то мере "онтологический" (т.е. проверять, не кладут ли время на склад, или не выписывают ли со склада код детали). Это было бы очень круто, это другой тип программирования вообще. Я не имею тут ввиду идею использовать формальный аппарат языковых типов для работы с ISO 15926 (это само по себе интересно, как способ реализации идеи), а изменение взгляда на программирование. При этом новом взгляде, ты программируешь, находясь в какой-то разделяемой информационной реальности, а когда ты из этой информационной реальности вываливаешься, то ты пополняешь ее -- пополняешь RDL. Это система утилизации и накопления знаний по формализации представления мира.
-- поскольку ISO15926 выразимо в терминах 201 понятия, то можно оптимизировать все вычислительные механизмы и механизмы хранения данных. Так, необязательно хранить все триплетами в triple store, возможно более компактное представление информации как в ОП, так и в percistence.
-- возможно, для ISO 15926 нужно програмировать не в логическом языке общего вида, а в какой-то специальной для нее "логике", или даже не "логике", а чем-то другом, в полной мере задействующем особенности этой онтологии.
-- программировать становится чрезвычайно легко: не нужно сначала делать SQL или SPARQL-запрос. Достаточно просто писать код, а данные доступны по определению: компилятор/интерпретатор сам разберется, как их вам вытащить для обработки, ибо данные языка и данные вашего хранилища информации -- это одни и те же данные. Как безопасно программировать в такой системе? Например, используя концепцию миров (Worlds) из проекта STEPS.
Риски: ISO 15926 не победит в соревновании верхних онтологий. Победит что-то более бедное (ISO 12006, или наоборот, какое-нибудь изобретенное через пару лет более богатое, или вообще что-то сбоку типа CYC или Gellish). Тогда все эти "оптимизации" -- путь в никуда. Причины могут быть разные, как "маркетинговые" или "ценза на умность" (как с функциональными и логическими языками), так и потенциальные крутые ошибки в самой онтологии 15926 (не формальные, а онтологические. Что-нибудь не то с универсалиями, или моделью времени, или ролями, или набором базовых отношений).
2. В полной мере используется идея intentional programming/language-oriented programming. Делается language workbench, в которой главной фишкой является посадка ее на PLM-подобную систему (то есть с доступом не в "базу данных", а в "репозиторий" или "семантическую сеть"). Похоже, что Intensional Software делает именно такую систему, но не факт -- можно уповать на то, что в Intentional Software снизу "самая крутая база данных Oracle" и доступ по SQL, а не "онтологический движок" и доступ незнамо на чем онтологическом (например, SPARQL, или чего похуже).
-- получается легкий способ иметь крутые программные интерфейсы для самых разных языков и предметных областей. Интеграция данных делается не только путем экспорта-импорта, но и путем доступа из разных спецредакторов (система интеграции разных АРМ -- предметных "автоматизированных" рабочих мест. Собственно, все PLM устроены именно как системы интеграции разных АРМ, но тут можно отойти от специфики САПР и пойти в разные другие предметные области).
-- используются самые крутые и радикальные наработки в нотационной инженерии (например, радикальный отказ от графики с доказательствами бОльшей продуктивности текстового кодирования любыми экспертами) и IDE (например, "пузыри кода" http://www.cs.brown.edu/people/acb/codebubbles_site.htm).
Риск: никто не знает, как сделать language workbench. Критиков существующих немногих систем много, но мало разработчиков. Поэтому вовсе не факт, что разработка language workbench для моделирования закончится успешно. Нужна либо плодотворная дебютная идея, либо гений-разработчик (с риском, что плодотворная дебютная идея ему в голову в обозримые сроки не придет). Ну, и возможны эффекты типа Двораковской клавиатуры (все очень круто, но никто не пользуется, ибо все очень круто) или того же функционального/логического программирования (все еще круче, но это как раз и ограничивает испольование -- хотя уже наблюдается какой-то прогресс, осталось подождать еще десяток лет).
3. Используются самые современные идеи программирования. То есть делается "как у всех", но получается в разы и разы компактнее по коду (а значит, гибче, быстрее и т.д.). Например, используются идеи проекта STEPS, или теория категорий в качестве аппарата вычислений.
-- получается система, которая в разы и разы проще для адаптации к потребностям того или иного заказчика. Адапторы лепятся пачками, на эту работу подряжаются студенты.
-- нагло используется логика самых высоких порядков, программирование на естественном языке и прочие изыски, сегодня неработоспособные -- но максимально выразительные. Через десять лет, когда разработка будет закончена, компьютеры как раз подоспеют в развитии, и получится самая быстрая и легкая в мире по программированию на ней система, хотя и самая немасштабируемая (это, правда, никого не остановит, как в случае с Ruby и прочими "медленными" языками).
Риски: все это исследовательские проекты, и придется попотеть, чтобы система хоть как-то задышала -- в исследованиях отрицательный результат ведь тоже результат. Да, компактность кода и скорость работы будут на высоте, гибкость будет чудовищна -- но если взять какой-нибудь допотопный и тяжелый Eclipse, и использовать его инфраструктуру (а хоть и вместе с кодами Simantics поверх него!), то первые результаты будут получены значительно быстрее. Можно писать сверхкороткие программы на COLA, а можно чуть более длинные на Python. При этом Python уже есть, а COLA эээ... якобы есть.
4. Забываем, для каких великих целей это сообщество появилось, и варим суп из топора: реализуем "обычный компилятор для необычных языков" (например, для кодирования для чуть-чуть расширенного ISO 24744, каковой код будем конвертировать потом в красивое текстовое представление, а когда-нибудь потом и в ISO15926 -- когда потребуется передать его в какую-нибудь PLM, если станет понятно, зачем). Назовем это Композер (и забудем, что внутри предполагалась платформа онтологического программирования, language workbench и прочие новомодные штуки). Надеемся на то, что в инструментальных системах конкурентов еще долго не догадаются реализовать такие преобразования (написать экранный плагин, подготовить адаптер и т.д.), и standalone компилятор некоторое время поживет и будет использоваться. За это время может в голову прийти какая-нибудь свежая дебютная идея. Полный agile.
Риски: проигрыш всем конкурентам по всем параметрам, но через некоторое время (когда они обратят внимание на соответствующий domain и потратят пару дней на то, чтобы получить то, чего тут будет программироваться несколько месяцев, а то и лет).
Я ничего не пропустил?
Пока мы особо ничего не делаем, кроме некоторых прикидочных экспериментов. Но я ожидаю, что вот-вот начнем делать. И тогда хотелось бы иметь ясные ответы на вопросы этого постинга: в чем фишка нашего проекта? Что именно из этой фишки мы реализуем в первых же строчках кода? Почему другим проектам после этого нас никогда не догнать -- и не потому, что там люди глупее, а потому что "за нас теория"?
Какова наша стратегия в .15926?
-- modeling tool siut, ибо в них внутре UML (modeling language!), и это просто инструментарий (Artisan Software, MagcDraw и далее по всему списку).
-- ontology/semantic engineering/modeling platform/environent (http://www.neon-project.org, http://topquadrant.com/products/TB_Composer.html), если там внутри OWL/RDF и SPARQL и "онтологический" сленг.
-- data manager и/или data repository (http://www.epmtech.jotne.com/products.41332.en.html, http://www.noumenon.org.uk/category.php?id=NQ== ), если внутри EXPRESS и онтологии типа ISO 15926. ISO 12006, протоколы ISO 10303 и речь идет о производственных данных.
-- странные небольшие решения типа Relatics/Gellish (семантический спредшит, как они себя называют -- http://www.relatics.com/Home/VideoErvaringenRelaticsGebruiker.aspx, а на деле что-то типа PLM общего вида для неинженерного документооборота), ОргМастер (с неизвестным науке языком внутри -- ),
-- современные NoSQL базы данных с кучерявыми средствами , которые определяют свой "язык моделирования информации" и "язык запросов". Их число растет, и к ним стремительно будут появляться "редакторы общего вида", "генераторы приложений" и прочая обвязка. Главное, они с самого начала ориентированы на "кучерявые" схемы данных, но обсуждают их в графовом языке. Именно отсюда растет Simantics как онтологическая платформа (https://www.simantics.org/simantics/documents/DoctoralThesis_Hannu_Niemisto.pdf -- базовый труд называется Locality and order-invariant logic). Как ни странно, но системы поставщиков современных PLM (Aveva, Bentley и т.д.) помещаются именно в эту категорию: там у них весьма навороченные движки, которые даже не притворяются чем-то онтологическим. А затем сверху густо намазана "схема", уж какая кому понравится (например, Bentley понравилось в ProjectWise использовать ISO15926).
Все эти промышленные моделеры делают одно и то же: выражают в терминах UML, или OWL/RDF, или EXPRESS (а на самом деле -- в терминах внутреннего какого-то нам неизвестного представления, которое может существенно отличаться от этих языков, а только экспортироваться/импортироваться в привычном для всех виде) разные большие или небольшие онтологии (с существующей внешней/глобальной RDL или без таковой, а разрабатываемой тут же на коленке) -- и затем дающие средства для редактирования этих онтологий "на базовом языке" или сразу средства редактирования соответствующих "моделям данных" (онтологиям же) данных в спецредакторах текстовых, табличных или графических DSL.
Хуже всего было бы ценой неимоверных усилий и напряжения мысли изобрести уже изобретенный кем-то велосипед, и тем самым повторить какую-то из уже имеющихся систем. Не нужно повторять ENOVIA, все равно ресурсов не хватит ее повторить. Нужно круто обогнать, чтобы у нас учились и нас печатали в учебниках как пионеров новых подходов.
Чем соревнуются между собой все эти абсолютно одинаковые по духу, виду, вкусу и запаху решения?!
1. Ценой. Хотя ситуация тут быстро меняется (взять хотя бы тот же Simantics, или NeOn -- ценовые модели бывают разные), и цена смещается с цены самого софта на цену получения на нем собственного решения. Цена получения прикладного решения зависит прежде всего от скорости его программирования. То есть задача получения дешевой платформы программирования/моделирования/онтологизирования превращается в задачу получения платформы дешевого программирования/моделирования/онтологизирования. Важно не то, сколько стоит IDE, а сколько ты будешь осваивать эту IDE, а затем с какой скоростью на ней сможешь работать.
2. Поскольку все эти системы предназначены для "моделирования всего на свете", то соревнуются интерфейсом моделирования -- он во многом влияет на скорость работы (сравните скорость редактирования в командном редакторе текстов и WYSIWYG. Я редактировал в командном редакторе! Это не лучший мой опыт). Хотя на вкус и цвет в этих интерфейсах товарища нет (кто любит тексты, кто графику, а кто сам не знает, чего хочет), некоторые интерфейсы убеждают, что в них моделировать быстрее и эээ... эстетичнее. Синтаксический/графический сахар имеет значение. Тут можно еще добавить, что речь идет об интерфейсе "для человека" и его программировании, а не программировании языкового экспорта/импорта/запросов. Об этом следующий пункт:
3. Легкостью программированя языковых трансоформаций (а также, по сопряженности, генерации "отчетов любого вида"). Либо у вас тут есть спецстредства в виде какого-то супер-пупер DSL, либо вам предлагают "писать на Java или любом другом языке программирования", обеспечивая "удобный доступ к данным", а там уж как сами справитесь. Поэтому моделеры делятся на "удобные для программирования адапторов данных" и "поддерживается большое число адапторов данных, входных и выходных языков и интерфейсов программирования". Понятно, что длина списка тут не имеет значения, но ежели у вас руководство по программированию "адаптера" составляет пару томов мелким шрифтом, то вряд ли ваша система будет лидером в этом соревновании -- как и система, где никакого руководства нет, а есть лишь "база данных и доступ в нее из языка программирования").
4. Языки моделирования с одной стороны не имеют значения, а с другой -- имеют значение. Если у вас UML со стереотипами, то у вас одни удобства. Если OWL 2, то совсем другие. Если фреймовый логический язык, или графовый из серии NoSQL экспериментов, или какой-нибудь незнаемой теории гибрид, то вы либо будете легко программировать вашу онтологию, либо не очень.
Но в принципе, это не самое важное место. Обычно заявляется, что "принимаем и отдаем любой язык", а дальше соревнование идет по переводу потенциального "любой" в актуальное (число реализованных адаптеров).
5. Вообще, число "адаптеров" к разным представлениям данных и другим системам. Программисты всегда делают заявления, что "система позволяет выразить любую информацию и обеспечить ее трансформацию в любое другое представление". Тут никакого соревнования нет, весь вопрос в том, выполнено ли уже программирование (иногда сводящееся к полной переписке всей системы с заменой базового представления данных) для интересующих вас языков, или не выполнено.
6. Временем оборота. Например, Intergraph SPF после каждого изменения схемы нужно перегружать, а вот Dassault Systemes ENOVIA V6 может и не перегружаться и меняться "на лету".
7. Масштабируемостью, что можно условно назвать и как "скоростью работы" (даже с условием того, что схема не меняется и все работает "как в обычных базах данных"). Если грузануть в такую систему подводную лодку или атомную станцию (примерно 4.5млн. индивидуальных деталей), то система либо еще будет работать, либо просто остановится.
8. Коллаборативность. Если пятеро человек начнут редактировать одну и ту же схему, что у них получится? Это самое непростое место, ибо это требует сложных архитектурных решений, повышенной отказоустойчивости, организации всевозможных хитрых API, существенно влияет на скорость работы, заставляет задумываться над разными моделями обеспечения прав доступа и т.д.
В исследованиях по маркетингу неоднократно было описано, что "вторая во всех категориях система не побеждает на рынке", нужно заранее выбрать, в чем стать лучшим, а в чем -- средним или даже чем пожертвовать и стать худшим.
В тех же исследованиях по маркетингу написано, что от знаменитых конкурентов к неизвестному вам перейдут в тот момент, когда ваш продукт будет по показателям не менее чем на 30% лучше (что бы это ни значило). Это означает, что побеждать придется не "по очкам" (тем более, что "по очкам" победить денег на разработку никаких не хватит), а принципиальными отличиями, и хотелось бы понять -- какими.
Какие есть варианты "принципиальной победы" в .15926 над всеми конкурентами? Что дает считать, что проект не пытается повторить то, что давно сделали (или вот-вот сделают) конкуренты, а делает что-то такое, что потом эти конкуренты все будут повторять?
Вот мои гипотезы:
1. Внутри существенно используются онтологические особенности ISO 15926. Как ни странно, но это "модель мира", а не просто "схема данных". Это на EXPRESS или F-logic схема данных, а на ISO 15926 модель мира. Поэтому:
-- можно ожидать, что программирование с использованием 15926-типов будет более осмысленным с точки зрения отношения к реальности. Это означает, что будет меньше ошибок программирования принципиально другого типа. Это означает, что можно делать не только "формальный" контроль типов, но и в какой-то мере "онтологический" (т.е. проверять, не кладут ли время на склад, или не выписывают ли со склада код детали). Это было бы очень круто, это другой тип программирования вообще. Я не имею тут ввиду идею использовать формальный аппарат языковых типов для работы с ISO 15926 (это само по себе интересно, как способ реализации идеи), а изменение взгляда на программирование. При этом новом взгляде, ты программируешь, находясь в какой-то разделяемой информационной реальности, а когда ты из этой информационной реальности вываливаешься, то ты пополняешь ее -- пополняешь RDL. Это система утилизации и накопления знаний по формализации представления мира.
-- поскольку ISO15926 выразимо в терминах 201 понятия, то можно оптимизировать все вычислительные механизмы и механизмы хранения данных. Так, необязательно хранить все триплетами в triple store, возможно более компактное представление информации как в ОП, так и в percistence.
-- возможно, для ISO 15926 нужно програмировать не в логическом языке общего вида, а в какой-то специальной для нее "логике", или даже не "логике", а чем-то другом, в полной мере задействующем особенности этой онтологии.
-- программировать становится чрезвычайно легко: не нужно сначала делать SQL или SPARQL-запрос. Достаточно просто писать код, а данные доступны по определению: компилятор/интерпретатор сам разберется, как их вам вытащить для обработки, ибо данные языка и данные вашего хранилища информации -- это одни и те же данные. Как безопасно программировать в такой системе? Например, используя концепцию миров (Worlds) из проекта STEPS.
Риски: ISO 15926 не победит в соревновании верхних онтологий. Победит что-то более бедное (ISO 12006, или наоборот, какое-нибудь изобретенное через пару лет более богатое, или вообще что-то сбоку типа CYC или Gellish). Тогда все эти "оптимизации" -- путь в никуда. Причины могут быть разные, как "маркетинговые" или "ценза на умность" (как с функциональными и логическими языками), так и потенциальные крутые ошибки в самой онтологии 15926 (не формальные, а онтологические. Что-нибудь не то с универсалиями, или моделью времени, или ролями, или набором базовых отношений).
2. В полной мере используется идея intentional programming/language-oriented programming. Делается language workbench, в которой главной фишкой является посадка ее на PLM-подобную систему (то есть с доступом не в "базу данных", а в "репозиторий" или "семантическую сеть"). Похоже, что Intensional Software делает именно такую систему, но не факт -- можно уповать на то, что в Intentional Software снизу "самая крутая база данных Oracle" и доступ по SQL, а не "онтологический движок" и доступ незнамо на чем онтологическом (например, SPARQL, или чего похуже).
-- получается легкий способ иметь крутые программные интерфейсы для самых разных языков и предметных областей. Интеграция данных делается не только путем экспорта-импорта, но и путем доступа из разных спецредакторов (система интеграции разных АРМ -- предметных "автоматизированных" рабочих мест. Собственно, все PLM устроены именно как системы интеграции разных АРМ, но тут можно отойти от специфики САПР и пойти в разные другие предметные области).
-- используются самые крутые и радикальные наработки в нотационной инженерии (например, радикальный отказ от графики с доказательствами бОльшей продуктивности текстового кодирования любыми экспертами) и IDE (например, "пузыри кода" http://www.cs.brown.edu/people/acb/codebubbles_site.htm).
Риск: никто не знает, как сделать language workbench. Критиков существующих немногих систем много, но мало разработчиков. Поэтому вовсе не факт, что разработка language workbench для моделирования закончится успешно. Нужна либо плодотворная дебютная идея, либо гений-разработчик (с риском, что плодотворная дебютная идея ему в голову в обозримые сроки не придет). Ну, и возможны эффекты типа Двораковской клавиатуры (все очень круто, но никто не пользуется, ибо все очень круто) или того же функционального/логического программирования (все еще круче, но это как раз и ограничивает испольование -- хотя уже наблюдается какой-то прогресс, осталось подождать еще десяток лет).
3. Используются самые современные идеи программирования. То есть делается "как у всех", но получается в разы и разы компактнее по коду (а значит, гибче, быстрее и т.д.). Например, используются идеи проекта STEPS, или теория категорий в качестве аппарата вычислений.
-- получается система, которая в разы и разы проще для адаптации к потребностям того или иного заказчика. Адапторы лепятся пачками, на эту работу подряжаются студенты.
-- нагло используется логика самых высоких порядков, программирование на естественном языке и прочие изыски, сегодня неработоспособные -- но максимально выразительные. Через десять лет, когда разработка будет закончена, компьютеры как раз подоспеют в развитии, и получится самая быстрая и легкая в мире по программированию на ней система, хотя и самая немасштабируемая (это, правда, никого не остановит, как в случае с Ruby и прочими "медленными" языками).
Риски: все это исследовательские проекты, и придется попотеть, чтобы система хоть как-то задышала -- в исследованиях отрицательный результат ведь тоже результат. Да, компактность кода и скорость работы будут на высоте, гибкость будет чудовищна -- но если взять какой-нибудь допотопный и тяжелый Eclipse, и использовать его инфраструктуру (а хоть и вместе с кодами Simantics поверх него!), то первые результаты будут получены значительно быстрее. Можно писать сверхкороткие программы на COLA, а можно чуть более длинные на Python. При этом Python уже есть, а COLA эээ... якобы есть.
4. Забываем, для каких великих целей это сообщество появилось, и варим суп из топора: реализуем "обычный компилятор для необычных языков" (например, для кодирования для чуть-чуть расширенного ISO 24744, каковой код будем конвертировать потом в красивое текстовое представление, а когда-нибудь потом и в ISO15926 -- когда потребуется передать его в какую-нибудь PLM, если станет понятно, зачем). Назовем это Композер (и забудем, что внутри предполагалась платформа онтологического программирования, language workbench и прочие новомодные штуки). Надеемся на то, что в инструментальных системах конкурентов еще долго не догадаются реализовать такие преобразования (написать экранный плагин, подготовить адаптер и т.д.), и standalone компилятор некоторое время поживет и будет использоваться. За это время может в голову прийти какая-нибудь свежая дебютная идея. Полный agile.
Риски: проигрыш всем конкурентам по всем параметрам, но через некоторое время (когда они обратят внимание на соответствующий domain и потратят пару дней на то, чтобы получить то, чего тут будет программироваться несколько месяцев, а то и лет).
Я ничего не пропустил?
Пока мы особо ничего не делаем, кроме некоторых прикидочных экспериментов. Но я ожидаю, что вот-вот начнем делать. И тогда хотелось бы иметь ясные ответы на вопросы этого постинга: в чем фишка нашего проекта? Что именно из этой фишки мы реализуем в первых же строчках кода? Почему другим проектам после этого нас никогда не догнать -- и не потому, что там люди глупее, а потому что "за нас теория"?
Какова наша стратегия в .15926?