Свежий пост про Smalltak и ещё не совершившуюся компьютерную революцию от Rafael Luque, https://osoco.es/thoughts/2020/06/notes-about-a-new-software-world/. Тамошнее предложение:
- Help programmers immerse themselves in the domain model and avoid any kind of distractions by working permanently within a “pure” conceptual modelling environment. This conceptual environment must provide a whole view of a software system, including all necessary aspects of its function (behaviour), interaction (system integrations and user interactions) and data (structure).
- Build a domain-aware runtime environment —for instance, a kind of domain-aware virtual machine— able to interpret any valid conceptual model. This runtime environment should enable very fast feedback loops based on our incomplete and still work-in-progress models.
- Experiment with new media for working with dynamic and powerful representations to think and learn about our software systems.
Ну да, я ровно об этом всё время и говорю. Только автор тамошнего текста примерно в том месте, в котором я был, тоже внимательно рассматривая DDD и тот же Smalltalk десяток лет назад. Потом я десяток лет долбился в поиски правильного хост-языка для SysMoLan, но кандидатом был уже не Smalltalk, а Julia. Увы, был неправ!
Сейчас мы вроде как докопались до некоторого прорыва, наши выпускники курсов онтологики (нужна работа с типами!) и "Системного менеджмента и стратегирования 2021" (там задаётся три уровня метамоделирования работы с какой-то деятельностью) начали выдавать на-гора actionable architecture (или она же architecture as a code) аккуратной работой с типами в средах программирования относительно нового типа: production tools (notion.so, coda.io — тысячи их). Это помесь редактора текстов, базы данных (моделирование и типы тут), hypercard/dynabook, экселя и просто программирования (есть API в произвольные программы и конверторы внешних структур в отображаемые форматы). Мечта Кея реализована: программы в таких средах верстаются, хотя это и не "объекты". Это оказалось ровно тем упрощением программирования, которое принёс эксель и которое хвалил Алан Кей, но дальше это усложнение экселя и баз данных, вводящее их вёрстку. В какой-то мере это продолжение линии МикроКалька (тоже была помесь редактора текстов с табличным процессором, проект заглох, ибо началась перестройка и все разработчики разбежались по разным странам и разным другим работам).
Прорыв характеризовался не одним, а несколькими разными моментами:
- основное моделирование ведётся не на уровне жёстко формального языка, формализм "как в базах данных" и меньше, "как в просто текстах". Вот это была засада: нужно было разобраться с языками архитектурного моделирования, и там отказаться от мета-мета-модели (сами они для мета-моделирования, это ж архитектура, она "в типах") и от визуального представления в пользу эээ... "богатого" (где таблички и реляции, где гипертекст, где аутлайны, где вёрстка этого всего вместе). Год был потрачен на SysArchi, это был тупик. Мы начали советовать делать архитектуру "в таблицах" (на самом деле, "в вёрстке разных представлений", в productivity tools вместо визуальных редакторов).
- рулить DDD нужно, имея в голове не только foundational ontology (язык представления "объектов и отношений"), но upper ontology. И она должна быть в голове модельера, а не в моделере (то есть мета-мета-модели в моделере по факту нет, она не слишком формальна!). Тут можно ещё обсуждать, но все ходы с явным кодированием в архитектурном моделере мета-мета-модели, которые мне известны, проваливались, по причине сложности трёхуровневого (мета-мета-модель для мышления и деятельности, мета-модель для практики какой-то деятельности и модель проекта с его экземплярами).
Мы сделали:
- более-менее тщательное мета-мета-моделирование SoTA для описания деятельности (онтологика, системное мышление и системный менеджмент). И там выскочило много неожиданного. Мета-мета-модель оказалась более-менее компактной и универсальной. Дальше мы показали примеры, что с этой мета-мета-моделью делать, как использовать для моделирования предприятия.
- взяли среду моделирования типа того же coda.io и там верстали "документы" как шаблоны/мета-модели. Грубо говоря, типы заголовков тамошних табличек аннотированы типами мета-мета-модели. Это делают наши выпускники, "системные модельеры/архитекторы".
- не обученные всем этим премудростям "просто сотрудники предприятий" становятся прикладными модельерами конечных объектов/экземпляров — операционных моделей предприятий. Просто заполняют строчки в табличках, чекают радиобаттоны, если это не табличка, а чеклист, а факты прочекивания и заполнения порождают потом задачи в issue tracker (и там стандартное программирование workflow, которое давно уже low code).
Работает от масштабов предприятия до масштабов небольших рабочих процессов. Так что уровней моделирования оказалось три, а не два, а наши выпускники как модельеры-архитекторы понимают, что они делают: на каждом мета-уровне моделирования какая-то своя терминология и соображения, и нужно владеть схематизацией (уметь обобщить что-то найденное в фирме, чтобы подвести под тип модели), так и (это оказалось необычно трудным для программистов) рендерингом (найти в фирме что-то, задаваемое схемой/мета-мета-моделью).
Так что пока мы на фронтире компьютерной революции, которую Алан Кей понимал по факту как "компьютер помогает человеку думать", то есть компьютер становится реальным экзокортексом, усиливающим мышление:
- вёрстка программ, domain-aware environment и т.д.. Всё как в предложениях статьи, с которых начинается этот текст.
- понимание, что conceptual modeling не должно проходить на строгом конце спектра формальности мышления (правильный ход тут — это подумать над вопросом "а что такое типы в псевдокодах?"). Концептуальное моделирование -- это псевдомодель данных (звучит подозрительно, но я просто хочу сказать, что это не формальная модель данных, а что-то типа псевдокода для компьютерного кода: менее формальное описание, не имеющее строгого синтаксиса и с более-менее вольно трактуемой семантикой).
Счастье в том, что у нас уже в нескольких фирмах такое пошло в production, то есть это не просто слова. Вот пара примеров такого моделирования (просто, чтобы показать, что всё это существует. Но наши студенты берут это как руководство к действию и начали успешно повторять, так что примеров больше, но на видео попала только парочка):
- https://www.youtube.com/watch?v=JlXeQxAkDf0 — тут моделирование требований и софтверной архитектуры
- https://www.youtube.com/watch?v=KAQzn5GvMNw — тут моделирование архитектуры предприятия с выходом на управление оргизменениями и операционный менеджмент
Что можно таким образом моделировать? Наши выпускники пробуют так "верстательно моделировать":
- целевую систему, которую нужно изменять (обычно техническая система, но отнюдь не всегда)
- enabling system как изменяющую эту целевую систему (это предприятие, и часто даже цепочка предприятий)
А почему мы говорим, что это исполняемые модели, исполняемые архитектуры? Исполнительные устройства тут — люди и компьютеры вместе. Экзокортекс, плюс extended cognition (то есть кроме традиционного представления что компьютер работает только с вычислением, можно думать о "роботе" с вычислителем, датчиками и актуаторами. Например, стадион при таком подходе — это робот, засасывающий в себя 40тыс. человек и перерабатывающий их безрадостных за пару часов в радостных).
А как мы убеждаемся, что всё это работает? У Дойча есть замечание, что computer science это естественная наука о доказательствах (доказательства того, что физический вычислитель в лице человека, классического электронного или квантового или ещё какого нибудь корректно моделирует поведение какого-то класса виртуальных объектов), и положения этой науки, как и всех остальных естественных проходят экспериментальную проверку. Так и тут, у нас эксперименты на живых предприятиях. У нас есть доклады по результатам на видео, но поскольку они для понимания требуют знания мета-мета-модели (а она в момент моделирования в головах, в моделере только мета-модель в виде заголовков таблиц и имён аутлайнов, и модель в виде содержания таблиц и аутлайнов), то разобраться с этими видео могут только выпускники наших курсов. Но это ничего необычного: если не прошёл какой-то курс (высшей алгебры, например), то решения задач (по высшей алгебре, например) будет тебе недоступным — хотя для прошедших курс всё будет понятным. Тут ровно то же самое, "научная эзотерика".
И да, вычислители могут изготавливать другие вычислители, а описания могут описывать другие описания (в том числе могут быть описания описаний вычислителей). Это уж как обычно, информатика такая информатика. Всё весьма контринтуитивно, и быстро с наскоку моделировать обычно не получается.
В жизни это выглядит как наш выпускник становится директором по развитию (то есть ему нужно навести порядок в организации, а потом научить организацию делать что-то новое) и ему нужен мощный инструмент моделирования, да ещё и с исполняемой моделью. А поскольку мета-мета-модель к этому моменту известна, они берут и моделируют (knowledge acquisition с прикладными сотрудниками предприятия, у которых есть прикладные знания. То же DDD, только под управлением мета-мета-модели, а "программные структуры, отражающие сущности (в том числе и типы) предметной области" — "модельные структуры, отражающие сущности (включая типы) предметной области". Модели исполняемы компьютером (automation) или людьми (всё-таки у нас workflow, определяемый по классике: часть работ в каком-то плане работ делают люди, часть работ делают компьютеры. План работ может верстаться on-the-fly после каждого шага работ).
Насчёт проверки, так тут онтологические проверки прежде всего: вкус арбуза выясняется его поеданием в реальной жизни, а не вычитыванием его многочисленных описаний. А перед поеданием, конечно, многочисленные review под управлением мета-мета-модели (там спрятаны эвристики, которые обращают внимание на важные объекты, задают вопросы, от ответов на которые нельзя уклониться — начиная с "убедитесь, что у вас в руках настоящий арбуз, а не его картинка. Бумажные картинки арбузов удивительно невкусны, вкус будет только у real thing", этот тест на "физичность системы" с огромным трудом люди проходят, в том числе и программисты).
Формальной валидации нет, но это не недостаток. Формальной валидации нет и у псевдокода, но это ведь тоже не недостаток! Её нет и у других систем подобного класса, которые создаются не за несколько часов, а за несколько месяцев в аналогичных масштабах. Вот этот уход от формальной валидации и строгости языка был ключевым. Мы искали DSL системного моделирования в неправильном месте на шкале формальности. Потом можно думать, чтобы брать какие-то узкие места и проводить там дополнительную формализацию. Но этого навалом, не хватало средств работы на уровне исполняемого псевдокода, не хватало средств не слишком строгой концептуализации. Вот тут была дыра! Повторюсь: её заполняли визуальные архитектурные языки с убогими мета-мета-моделями, цена моделера от двух до десяти тыс. баксов за рабочее место.
Мета-мета-модель даёт средства обсуждения того, как из фона вниманием выделять фигуры, существенно влияющие на причинно-следственные отношения в деятельности. Дальше должно быть много-много страниц текста, которые объясняли бы, что такое деятельность и как она связана с прагматизмом и агентностью (не путать с прагматикой) и как её описывать, контрфактуальность в описаниях причинно-следственных отношений, почему важно учитывать системные уровни в описаниях и отдельно обсуждать трансдисциплины и интеллект и т.д.
Вот мы как раз пишем эти страницы текстов и публикуем их в виде курсов. То, что я рассказываю, мы быстро-быстро отчуждаем и переводим на уровень простого знания, которому можно обучить. Увы, это больше похоже пока на пару лет обучения, чем на пару месяцев. Но ничего, магистратура пару лет занимает, и все как-то справляются. Тут ровно то же самое.
И да, там столько всего оказалось связанного, что мы и сами не ожидали. Мы назвали это интеллект-стек. Ведущие практики его уровней: понятизация, собранность (mind and body control), онтология, логика, физика, информатика, познание, обучение, методология, праксиология, системное мышление, деятельностные кругозоры (инженерия, включая системную информатику и системное образование, менеджмент, включая инженерию предприятия, предпринимательство). Если вот это всё не слишком уложено в голове, то моделирование идёт плохо. Если хорошо уложено, то должность становится "директор по развитию" (название может, конечно, варьироваться, но смысл понятен), и работа — ровно вот это мета-моделирование на основе мета-метамодели, с оставлением прикладного моделирования сотрудникам предприятия (они заполняют таблички, получают тем самым модель предприятия, описание важных объектов, которые нужно отслеживать своим вниманием в предприятиях).
Только сейчас становится понятно, что же такое мы сделали. Это результат как минимум трёх моих длинных (по нескольку лет каждый) проектов:
- PraxOS (мета-мета-модель предприятия и деятельности)
- SysMoLan (системное моделирование, которое оказалось на "верстательном языке")
- вычислительное мышление (создание нового курса информатики).
Ссылки на всё упомянутое не ставлю (все ходы записаны, этот пост просто обобщение ранее сказанного). Кто следит за этим блогом, тот всё и так поймёт. Кто не следит, тот пусть погуглит по моему блогу, в гугле нужно для этого к поисковым словам добавить site:ailev.livejournal.com
UPDATE: продолжение в https://ailev.livejournal.com/1578058.html
Источник: https://ailev.livejournal.com/1577769.html