Системное моделирование на SysMoLan в IME Codia (interactive modeling environment СOda + julIA)

Я пишу о профессиональной (а не low code) среде системного "текстокодного" моделирования, это и будет IME для SysMoLan. Быстрая вёрстка метамоделей/форм, удобное заполнение этих форм данными модели, а язык нужен для быстрой и мощной обработки этих моделей сниппетами кода на нормальном языке программирования.

Я понимаю, что это у меня абстрактная хотелка такая, но мои абстрактные хотелки часто сбываются, так что пусть это тут мелькнёт в письменном виде. Как говорится, "запомните этот твит".

В посте:

  • Системное моделирование предприятия: чем сегодня стал SysMoLan.
  • Среда моделирования для SysMoLan: сегодня это coda.io.
  • Codia = coda+julia как IME (interactive modeling environment).

Системное моделирование предприятия: чем сегодня стал SysMoLan

По факту я признал, что с SysMoLan мы глядели не на тот конец спектра формальности мышления: ещё в 2017 году мысли бродили вокруг embedded DSL на Julia (древняя цепочка SysMoLan -- https://ailev.livejournal.com/1443879.html, но мысль про SysMoLan как DSL на Julia была и в сентябре 2019, когда появился чат о типах в языках программирования: https://ailev.livejournal.com/1488488.html и далее обсуждалось много разных других опций для SysMoLan -- https://ailev.livejournal.com/1489546.html). А потом мы окончательно разочаровались в SysArchi сразу по двум линиям: визуальность как неудобное моделирование и плохая мета-метамодель как плохое моделирование.

В конечном итоге в ходе нашего курса "Системный менеджмент и стратегирование" в ответ на вечный вопрос "а как разговаривать с сотрудниками, которые не знают этого птичьего языка системного менеджмента" выработалась практика с несколькими уровнями моделирования/демоделирования. Если у вас несколько уровней моделей, то для каждого уровня в соседние уровни ведут две операции -- схематизации/моделирования от модели в её метамодель и конкретизации/рендеринга в моделируемую сущность. В моделировании предприятий выделение объектов идёт в несколько онтологических уровней, условно называемых foundational ontology, upper ontology, middle ontology, work ontology. И ещё есть операционная модель, сами данные об экземплярах, которые часто вообще не относят к онтологии/модели данных, ибо "это и есть данные, для которых делается модель данных":

  • Разговор об объектах, отношениях, атрибутах, типах — это foundational ontology (обычно десяток-другой понятий). Это мы разбираем в курсе онтологики. По-другому это называем мета-мета-мета-метамодель или M4. Про мета-моделирование можно узнать, например, из википедии, https://ru.wikipedia.org/wiki/Метамодель_(информатика), ибо мы не любим сами придумывать предметные области, не мы придумываем всю эту терминологию. M4 -- это тоже более-менее традиционное обозначение уровней мета-модели (скажем, в стандарте MOF определяется до десятка уровней мета-моделирования, хотя говорится, что на практике хватает трёх-четырёх. Вот и нам хватает четырёх). Уровень мета-мета-мета-метамоделирования М4 редко обсуждается, ибо это теория концептов (язык, на котором мы разговариваем про пространство-время-людей-модели). Это язык, на котором обсуждается сама машинка типов, как мы её описываем. Холст, на котором рисуются онтологии. В курсе онтологики, конечно, это обсуждается. Нас тут интересует из теории концептов так называемая theory theory, https://iep.utm.edu/th-th-co/. Это моделирование выполняют разработчики наших курсов, которые инсталлируют это знание в головы наших выпускников, но не в их компьютеры.
  • Разговор о системах, практиках, агентах, представлениях пространства и времени, формах и ролях — это upper ontology, мета-мета-метамодель или M3. Курс системного мышления и курс онтологики вместе. Это тоже наши разработки, это тоже идёт в головы выпускников, документировано в виде текстов учебников и книжки Криса Партриджа.
  • Разговор об объектах менеджмента, инженерии, предпринимательства и иного какого-то труда — middle ontology, мета-метамодель или M2. Курс системного менеджмента, это тоже разработано нами и идёт прямо в голову выпускникам. Ничего из M4, M3, M2 сотрудникам предприятия знать не нужно, на этом языке им не нужно разговаривать.
  • Разговор об типах объектов предприятия — work ontology, метамодель — M1. Моделирование выполняется нашими выпускниками в ходе метамоделирования совместно с сотрудниками предприятия. Сотрудникам знать M1 надо. Ключевой момент в том, что предполагается табличное, текстовое, графовое (аутлайны) моделирование, где типы объектов предприятия -- это заголовки табличек, упоминания объектов в тексте (например, заголовки), какие-то наименования нелистовых узлов аутлайна. Это абсолютно понятно работникам. M2 это типы для этих заголовков, существование этих типов нужно для проектирующих это "псевдокодное" или как мы говорим "текстокодное" представление, то есть наших выпускников.
  • Разговор об экземплярах на предприятии — операционная модель, M0. Выполняется сотрудниками предприятия путём заполнения табличек данными, заполнения пропущенных мест в абзацах текста, указанием листовых объектов в аутлайнах.

То есть определение объектов в мире многоуровнево, разделено по разным командам и растянуто по времени, а не в один приём: "не знаю ничего — о, всё отмоделировал". Именно об этом подробно говорится при рассмотрении архитектуры предприятия в курсе системного менеджмента, даются примеры моделирования. Для понимания, конечно, нужно закончить курс онтологики и как-то освоить системное мышление. Вот пара видео наших выпускников, которые после знакомства с нашими курсами воспринимаются как "руководство к действию": https://www.youtube.com/watch?v=JlXeQxAkDf0 и https://www.youtube.com/watch?v=KAQzn5GvMNw. А ещё нужно иметь моделер для вот этого "текстокодового" моделирования.

То есть определение объектов в мире многоуровнево, разделено по разным командам и растянуто по времени, а не в один приём: "не знаю ничего — о, всё отмоделировал". Именно об этом подробно говорится при рассмотрении архитектуры предприятия в курсе системного менеджмента, даются примеры моделирования. Для понимания, конечно, нужно закончить курс онтологики и как-то освоить системное мышление. Вот пара видео наших выпускников, которые после знакомства с нашими курсами воспринимаются как "руководство к действию": https://www.youtube.com/watch?v=JlXeQxAkDf0 и https://www.youtube.com/watch?v=KAQzn5GvMNw. А ещё нужно иметь моделер для вот этого "текстокодового" моделирования.

Среда моделирования для SysMoLan: сегодня это coda.io

Наши выпускники провели исследования, и выяснили, что победителем тут выходит моделер https://coda.io/, русскоязычный чат https://t.me/codaio_russia. Снаружи там разговор про документы, что может смущать своей обыденностью, но внтури это "живые документы" как тот самый гибрид экселя, СУБД, аутлайнера и редактора текстов, и там программирование на языке формул (как в экселе, как в языке запросов в базе данных, и как когда-то программировали на Visual Basic разные обработки в Ворде).

Вот пример живости языка (игра "змейка" на языке формул в coda.io): https://community.coda.io/t/lcd-display-snake-game/7754. Вот дизайн-цели языка: https://coda.io/@coda/designing-the-coda-formula-language. Вот кратенько про язык формул -- https://help.coda.io/en/articles/2695142-the-basics-of-coda-formulas

Итак:

  • SysMoLan оказался набором мета-моделей/онтологий (M4-M2, то есть foundational, upper, middle ontologies), в моделере их нет
  • моделером для SysMoLan оказались productivity tools ("не царевна, не лягушка, а неведома зверушка") в целом, а из них пока выигрывает coda.io

Дальше можно вспомнить десятое правило Филиппа Гринспена (https://ru.wikipedia.org/wiki/Десятое_правило_Гринспена ), что "Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp". Смысл правила был в том, что если вы пишете на низкоуровневом языке, то вам требуется увеличить мощность этого языка. Современные языки содержат средства расширения. Например, в Julia именно с этой целью было введено метапрограммирование, которое было отмоделировано авторами языка как раз по образу и подобию лиспа (при этом первые реализации Julia внутри содержали и самый настоящий интерпретатор одного из лисповских диалектов, femtolisp -- https://discourse.julialang.org/t/the-role-of-femtolisp-in-julia/1902).

Языки формул не слишком удобны для программирования. На языке формул coda.io можно написать игру "змейка", но это программистский подвиг. В Excel как системе попроще до сих пор есть проблемы с полноценным программированием на тамошнем языке формул, вот я писал в январе 2021 про проект Microsoft, пытающийся добавить в Excel полноценный язык программирования: https://ailev.livejournal.com/1554122.html. Я там поминал и AirTable и ClickUp, хотя и не coda.io — лидер в productivity tools тогда был не самым очевидным. Повторюсь: для меня Excel -- это такая standalone coda.io с очень урезанными возможностями по части редактирования текстов, программирования, поддержки функций СУБД и удобного API для связи с другими программами. И этот Excel завоевал мир. Вот coda.io -- это Excel на стероидах, и этот productivity tool, появившийся только в 2019 году тоже имеет все шансы захвата мира.

И неминуемо станет задача усиления тамошнего языка формул. И тут нужно сказать, что Алан Кей, когда говорил о вёрстке программ, про важность примера электронных таблиц как парадигмы программирования, ставил задачу вот такой мультипарадигмальной работы. Сделано там было, увы, не очень много. Впрочем, современные мультипарадигмальные языки не очень-то мультипарадигмальны в ближайшем рассмотрении. Но и не очень монопарадигмальны. Если к функциональной, объект-ориентированной, аспектной, акторской и т.д. парадигмам программирования добавить табличное программирование (нужно вспомнить времена Lotus 1-2-3 и Supercalc, когда electronic spreadsheets активно обсуждались именно в этом плане. И даже группа Аттик сделала МикроКальк как уникальный гибрид редактора МикроМир и встроенных в него электронных таблиц. Идея развития "программирования на таблицах" была очень, очень популярна -- пока Майкрософт не съел всех, кто экспериментировал в этой области).

Codia = coda+julia как IME (interactive modeling environment)

И тут я опять вспоминаю про симпатичный язык Julia, который решил проблему двух языков (скоростной разработки как на Питоне и скоростного выполнения результата разработки, как на Си):

  • с языком к 2021 году более-менее разобрались, с компилятором тоже.
  • с тем, как расширять язык в сторону формального (имитационного, на языке программирования) моделирования на примере Modia и макроса model, а также всякими autodiff — уже тоже понятно. DSL в Julia строятся штатно, пакетная система устроена понятно и встроена в язык.
  • это уже более-менее популярный язык.

Моё предложение: для Julia нужно делать не IDE (interactive development environment типа Visual Studio Code или Jupyter, или Pluto), а IME (interactive modeling environment)/productivity tool. Другими словами, для Julia среду разработки нужно делать не как статические тексты с полями для кода и местами для графиков (notebooks), а как более богатую среду, включающую не только редактор текстов и места для графиков и слайдеров (вёрстка программ, которую так хотел Алан Кей!), а ещё и таблицы и аутлайны и всё остальное, что можно найти в coda.io.

Вообще-то в Excel и coda.io язык формул служит для решения задач lowcode "не очень программистами", то есть это специализированный язык, привязанный к табличному программированию. Это ни разу не язык программирования в привычном виде, ни разу не похожий на Julia. Хотя в notebooks мы привыкли видеть обычные языки программирования. Конечно, если взять язык формул из парадигмы программирования электронных таблиц (немного рассказа про это тут https://www.10studio.tech/docs/fundamentals, литературы такой много) и сказать, что мы его просто заменим на "традиционный" мультипарадигмальный текстовый язык вроде Julia, ничего не получится, нужно думать.

А ещё языки lowcode особо хвастаются тем, что они доступны "не очень программистам", а вот такие языки, как Julia доступны "очень даже программистам", это язык не для начинающих. Но это предмет традиционного холивара: смотря как и кого и чему вы учите в плане языков программирования. Не забываем, что группа Аттик ставит задачу обучения людей программированию на Ершоле/Паскале в объёме знаний, нужных для сдачи ЕГЭ к концу начальной школы. С другой стороны, все системы lowcode оказываются плохо пригодными для промышленных разработок -- как раз мощности языка в них не хватает, чтобы поддерживать нормальное программирование, и как с coda.io рисование игры "змейка" в таких системах становится из получасового упражнения приключением по преодолению ограничений убогости языка. Оставим этот холивар "зачем обычный язык программирования в productivity tools" за пределами нашего поста.

Так же оставим за пределами нашего поста и вопрос, как будут помогать людям моделировать и программировать (это одно!) программы AI типа недавно показанного GitHub Copilot на базе платформы OpenAI Codex (https://ailev.livejournal.com/1578279.html), без этого скоро уже будет нельзя говорить ни о каких средах программирования/моделирования.

И оставим за пределами поста вопрос, что в очередной версии coda.io собираются делать в части языка программирования, ибо coda.io ставит и вопрос полноценного программирования в своей среде. Но вряд ли мы увидим в качестве языка программирования там Julia.

Но почему нам в coda.io потребовался именно Julia как язык? Это ещё один холивар, на эту тему тоже сломано немало копий, не это тема моего поста. Я пишу все эти "оставим за пределами моего поста разные скользкие вопросы" только для того, чтобы читатель понимал, что о существовании этих (и множества других) вопросов автор поста знает, и какие-то ответы у него есть. Не первый год автор пишет про разные среды моделирования и про Julia, поэтому все вопросы на эту тему ему уже пару десятков раз задали, ваши предложения типа "надо брать не Julia, а __мой любимый язык__" тут будут встречаться со вздохом, ибо это предложение реализует сама coda.io (или конкурент coda.io, который захочет иметь надёжное конкурентное преимущество и рискнёт). То же про coda.io -- почему? Вдруг завтра будет что-то круче? Coda.io лучше других гибридов экселя, базы данных и текстового редактора главным образом из-за возможности указания в ячейке таблицы связей 1:N, другие табличные системы могут только 1:1.

Так что я говорю о профессиональной (а не low code) среде системного "текстокодного" моделирования, это и будет IME для SysMoLan. Быстрая вёрстка метамоделей/форм, удобное заполнение этих форм данными модели, а язык нужен для быстрой и мощной обработки этих моделей сниппетами кода на нормальном языке программирования.
Я понимаю, что это у меня абстрактная хотелка такая, но мои абстрактные хотелки часто сбываются, так что пусть это тут мелькнёт в письменном виде. Как говорится, "запомните этот твит". Назовём пока этот проект Codia (из Coda + julIA, по примеру Modia из modelica+julia).

UPDATE: обсуждение в чате блога с https://t.me/ailev_blog_discussion/10059