Обсуждение

в https://habrahabr.ru/post/267749/ я предлагаю для моделирования комбинацию вертикалей Захмана из http://ailev.livejournal.com/951732.html и туннельного моделирования из http://philos-cafe-spb.livejournal.com/69306.html

Год назад мы обсуждали UI-сторону этой темы (тред "Property Grid в интерфейсе" в почте). Основные ответы с тех пор нашлись. Но не все мне понравились. Паззл сложился в профессиональный (веб-и-не-только) браузер. То есть, "браузерная" работа с вьюхами приложений (независимо от domain-specific stuff), но с опциями включения определённых интерфейсных решений, характерных для IDE/CAD, но адаптированных для новых условий. Сложно в проектировании, легко в реализации. За исключением одного момента... Как среда для работы только своих же (или партнёрских) приложений моделер превращается в очередной ущербный Eclipse. А интеграция через хаки старых приложений, рассчитанных на работу непосредственно под операционкой, себя не оправдывает - глючить будет (примерно как Windows-приложения под Wine), и идеология другая - привет изумление пользователей "а как мне открыть [...] на отдельной вкладке???". Однако, есть веб, где грабли диких стандартов, но встраивание, интеграция и многовкладочность вполне в порядке вещей. Его поддержка - ключевой момент, важная составляющая ценности моделера. То есть, помимо нативных возможностей, необходимо создание ещё одного современного веб-браузера, с дополнительными API интеграции веб-приложений. И эта часть, даже на базе Chromium, весьма трудозатратна, выходит за рамки тех ресурсов, что были у нас на проекте .15926. Ответы есть, ресурсов нет. Проще не стало. :)

И там ещё нужно разобраться с notebooks, которые дают ещё один вариант оконной вёрстки -- хотя их можно считать iframes в браузерных окнах. Всё сложно и ресурсоёмко, это правда. Но радует, что ответы потихоньку собираются в более-менее целостную конструкцию -- два моих последних текста ровно об этом. В какой-то момент эта конструкция может стать настолько убедительной, что и ресурсы появятся.

По части notebooks - да, выгодно рассматривать ячейки как вьюхи (которые сами могут тоже содержать вьюхи, разумеется). Кстати, в Jupyter сейчас тоже хотят сделать более профессиональный UI, на браузеры не замахиваются, просто пилят классическую многопанельку в пределах одной вкладки. Выглядит так: https://www.youtube.com/watch?v=T385txAYSt8&t=35m30s

Кто и как в таком мегамоделере будет делать и отслеживать correspondence между AD elements и соответствующие им correspondence rules? Представляется, что это один из ключевых моментов, потому что я не представляю, как иначе удержать все это богатство, чтобы оно не развалилось. Если отдавать эту работу сетке-помощнику, то как ее учить?

Конечно, отдавать эту работу "когнитивной архитектуре" (где сетки тоже будут). Вручную справочные данные невозможно отслеживать, наш опыт с .15926 это отчётливо показал. Единственный путь тут прорваться -- это прислеживать за какой-то когнитивной архитектурой, которая что-то будет в этом плане делать. Прислеживать, а не онтологизировать вместо неё. С другой стороны, сама такая система как раз и является инфраструктурой для удобного мэппинга, для удобного поддержания correspondences! Без этого ведь отслеживать соответствия будет не в чем, ни глазом посмотреть, ни внести изменения, ни записать соответствие, а главное -- отладить автоматизацию всего этого хозяйства будет нельзя!

Конечно, вью рекурсивны во внешнем представлении. Слово "браузер" я бы не использовал: слово "редактор" тут более адекватно, а лучше "моделер". Ибо для изменения чего-то в браузере даже представить себе невозможно, как это делается inplace, поэтому-то все с браузеров начинают, а потом поверх вылетают всякие плашки, где уже можно что-то редактировать в распарсенном на поля виде. Я же предлагаю поэтому с браузеров даже не начинать. Тут "ноутбук" много лучше (ибо в него ещё и пишут). Только от "сверху вниз ячейки-полоски" нужно заменить на обычную вёрстку, и всё пойдёт -- хотя намучиться придётся с определениями "правильной последовательности" (но и тут манга нам рассказывает, как поступать в таких случаях сложной вёрстки вьюшечного нарратива). В принципе, если начинать что-то делать, то брать ту же Julia как родной для Jupyter язык и вливаться в разработку того же Jupyter.

А есть что-нибудь более развернутое про то, как эта "когнитивная архитектура" должна быть устроена?

Так я, вроде, как раз этот пост для этого и писал, нет? Вот это вот (плюс предыдущий пост про системную информатику, плюс тексты по ссылкам из этих постов) -- набегает всего довольно много, и даже примеры-прототипы, куда смотреть, я указал. Хотя я понимаю, что много осталось не высказанным (тут нужно учитывать, что я ещё исхожу из опыта возни с различными PLM/САПР, плюс наблюдения за scientific computing, плюс опыт собственной разработки .15926 в части онтологий, и поэтому моё собственное понимание, конечно, чуток пошире чем изложенное в посте). Тут два варианта: либо книжку писать про системную информатику, либо сразу делать какую-то жужжалку, ибо книжки без жужжалок мало кого убеждают, а жужжалки без книжек иногда срабатывают. Вот .15926 не сработал, больно экзотический формат -- получилась типичная скрипка Энгельбарта, на ней никто учиться играть не захотел )))

Я просто не могу понять, где во всем этом большом зоопарке живет "удержание целостности"? Впрямую правила, отвечающие за целостность, непротиворечивость и т.д. прописать невозможно, потому что слишком много всего и сложно охватить и человеческим умом и какими-то формальными правилами. При этом довериться нейронной сетке тоже боязно: одно дело не найти 6% котиков на фотографиях, другое - 6% противоречий, из-за которых эта космическая станция не взлетит.

Сейчас удержание целостности работает на ручных проверках (поэтому так долго и дорого). Автоматизация только добавит качества. Сам этот проект -- это упрощение-ускорение-фокусирование традиционной разработки, даже если не учитывать какие-то компоненты, круглые сутки отыскивающие коллизии. Так что ответ на ваш вопрос: "будет не хуже чем сегодня", а вопрос про качество и надёжность работы когнитивных архитектур -- это для даной темы обустройства мегамоделирования очень частный вопрос, на грани оффтопа. Конечно, существуют самые разные пруверы, которые проверяют содержимое PLM/ALM, а также корректность отдельных частных моделей. Их число и качество обязаны расти. Но для начала нужно сделать инфраструктуру, в которых их можно было разрабатывать. Вот мы сделали, например, .15926 -- и каждый раз на каждом такте разработки вставал вопрос, делать ли нам проверки целостности содержимого базы тамошних знаний прямо сейчас, или подождать? Каждый раз отвечалось: чтобы проверять целостность, для начала нужно положить всё в одно место и дать механизмы изменений по результатам проверки. То есть возможность редактирования, прохода алгоритмов, контроль конфигурации сначала (инфраструктурная функция), что там с содержанием моделей и как они друг другу противоречат (содержательная функция) потом -- это приоритеты при разработке инструментария. При разработке целевой системы, конечно, приоритеты обратные: сначала контролируем содержание, а лаптем или алгоритмами высокого интеллекта -- это уж потом.

Браузер штука народу понятная, сейчас в нём всякие гуглдоксы водятся, а что в древности можно было только "просматривать" - так это археологам интересно. Ноутбуки малоизвестны, моделеры страшны на вид. Так что объяснять лучше с "как браузер, но добавлено полезной магии". Тем более, что большинство вкладок будут именно на почитать/посмотреть. Но в названии продукта использовать более универсальные термины, вроде "desktop". :) Julia в Jupyter применяется только внутри адаптера для себя же. Всё на Python плюс браузерный клиент на Javascript.

так Unity / Lua народу еще понятнее Особенно - школьной молодежи, которую удобно привлекать для генерации идей

готовые онтологии - замечательный материал для обучения

зачем такая централизация? можно иметь сервисы, которые получают коллекцию правил и коллекцию данных и возвращают конфликты в данных при использовании правил

Браузер будет страшно путаться с HTML-браузером, вот и Jupyter использует тоже браузер -- ровно как GoogleDocs. Тут же BeyondDocs получается, при этом ещё и развилка есть: клиент браузер (с наследованием всех наворотов) или толстый клиент (внутри которого, ежели чего, и браузер HTML5 можно вызвать, и Atom -- не вопрос). Но "сервер-браузер" для бэкенда-фронтэнда тут правильная аналогия в том, что подразумевается какая-то пустая системная инфраструктура, независимая от возможных приложений. Скелет без мяса, язык без слов, игровой движок без игры. Интересно, что я с трудом могу подобрать слово (кроме "платформа", "движок") для подобной системы, ибо точнее всего тут application framework за малым исключением: эта штука не для приложений, а для тихой бэкендной работы, интерфейсы там "системные", а не "пользовательские". Я бы назвал этот класс систем system workbench: верстак для системных описаний. Нужно очень осторожно выбирать инструментарий реализации. Если аккуратно строить "с нуля" (скажем, брать ту же Julia, и ваять -- начиная с повторения хотя бы функций Jupyter), то высоко не построишь в силу нехватки ресурсов. Но будет шустро, компактно, понятно, сопровождаемо. Если строить на основе динозавров, то заодно получаешь все окаменелые фекалии внутри этих динозавров, которые накапливавались с каждым немаленьким релизом -- включая архитектурные плюхи первых версий. Достаточно посмотреть на Eclipse, чтобы понять о чём я. Хотя этот Eclipse ровно такой же "браузер" (пока внутрь не заглянешь), поэтому может появиться ложная мысль, что его можно "быстренько подхакать по потребностям". Что Julia внутри Jupyter просто сидит, как родная, но на ней ничего не написано, это понятно. Это ж всё не с нуля писалось, а просто переработанная чуток версия IPython -- никаких иных целей не ставилось, а "родность" Julia там из-за того, что это просто был стратегически (они ж все детки NumFocus) первый язык, на котором отлаживалась многоязыковость ноутбуков. Я вот думаю, что бы они делали, если бы можно было Jupyter с нуля писать -- какая там была бы архитектура. Но с нуля только отчаянные ребята самой Jula начали писать, и то их обвиняют, что всего тысяча родных пакетов -- это мало (при всех заверениях, что можно брать и сишные, и питоновские, и разные другие пакеты в Julia, да и сама Julia умеет прикидываться чем угодно -- даже оригинальными сями, вот: http://juliacomputing.com/blog/2016/03/10/j2c-announcement.html). Тут нужно понимать, что language workbenches пытались делать примерно то же, что все остальные: но провалились в большинстве своём, ибо мейнстрим оказался в том же самом шустрей и разворотливей. Помним, что лисп-машины проиграли тоже потому, что мейнстрим оказался не менее производительным даже на лисп-программах. И риск-процессоры оказались в итоге не быстрей мейнстримных. Тут нужно чётко понимать, в чём фишка и выигрыш, и делать именно её: иначе подождать ещё лет пять, и всё само реализуется, тот же Google Docs будет через браузер поддерживать "документы и базы данных произвольных форматов".

Language workbenches и многое другое провалилось по той причине, что рисков было на порядок больше, чем создаваемой ценности. Кстати, там же и .15926 - пользователям требовалось не только обучение, но и принятие всех рисков стандарта. В то же время, multilanguage IDE и различные инструменты мэппинга между старыми стандартами очень даже живут. В общем, эффективнее начинать с ценности здесь и сейчас, не отягощённой принятием новых рисков.

Если так рассуждать, то всё уже есть: тот же Eclipse для одних случаев и Jupyter для других, можно брать ещё и разные PLM, если хватать не будет )))

Нет. Дело не в существующих продуктах, а в существующих потребностях. Разница между: 1. Обещается, что вы можете получить ценность X, если затратите время на принятие/обучение. Это риск. 2. Обещается, что вы можете получить ценность X, если не только сами затратите время на принятие/обучение, но существенное количество людей в определённой категории сделает это же самое. Более существенный риск. 3. Обещается, что вы можете получить ценность X, если [...], но также вы получаете понятную ценность Y прямо сейчас. Польза.

Это просто означает, что "из коробки" должно поддерживаться много viewpoints, разных типов (языки, форматы данных типа XML и JSON, ноутбуки для каких-то учебных курсов, простой HTML5, и т.д.).