Category: it

Category was added automatically. Read all entries about "it".

2021 год

lytdybr

Начал шестую переписку "Системного мышления", с кейсами в версии 2020 года 518 страниц A4: завёл файл, сделал первую ритуальную правку (заменил год 2020 на 2021 в названии). У меня планы обойтись минимальным количеством изменений основного текста (я им более-менее доволен на сегодняшний день), но нужно сделать следующее:
-- привести в соответствие с онтологией интеллекта и мышления, а также разбивкой на мыслительные практики интеллект-стека, которые я дал в "Образовании для образованных 2021" (по большому счёту, это главное: жизнь поменялось, понимание поменялось, нужно обновляться). Чуток там и терминологию подправить (скажем, "труд" вместо "деятельности" звучит сильно получше).
-- чётче прописать про целевую систему, что её нахождение -- это предпринимательство, и никакого алгоритма быть не может. Это уже написано, но запросы на "покажите алгоритм" идут, надо ПРОПИСАТЬ ПЯТЬ РАЗ В ТЕКСТЕ, ЧТОБЫ ХОТЬ ОДИН РАЗ ЗАМЕТИЛИ: АЛГОРИТМА НАХОЖДЕНИЯ ЦЕЛЕВОЙ СИСТЕМЫ НЕ БЫВАЕТ, ЭТО ПРЕДПРИНИМАТЕЛЬСТВО! (ага, ещё и капслоком, и в рамочку -- не слышат, не читают, не замечают, игнорируют. Надо как-то пробиться).
-- доразобраться с терминологией. Первые тут кандидаты -- интерес и потребность (ибо значения далеки от бытовых, студенты путаются сильно, последняя путаница вот только что в чате произошла с https://t.me/systemsthinking_course/15729, а проблема поднималась ещё в сентябре 2020 -- первый абзац в https://ailev.livejournal.com/1538265.html как раз про concern).
-- digital twins (хотя это больше системная инженерия, но само понятие таки нужно добавить в мышление -- ибо это общее для всех систем, включая и обеспечение, и окружение и так далее, digital twin network и digital engineering), и экономическое рассмотрение в том числе от них идёт, вот: https://ailev.livejournal.com/1570630.html.
-- вот тут длинный списочек -- https://ailev.livejournal.com/1565649.html
-- в том числе в том длинном списочке и про 4D паттерны, то есть ритмику, и про уточнение модели танца. А я ещё хочу добавить в модель танца как пример три view на нескольких масштабах/scales времени: общее движение, собственно танец и музыка с её ритмикой. Заодно это же упражнение в моделировании должно показать как-то работу с решётками/lattice, а не стеками -- то есть более честную и производственную, а не в целях образования, работу с онтологиями, нежели "стеки практик", которыми мы увлекаемся в последнее время. Но вот это чистое исследование, мысли на эту тему есть, а модели ещё нет.
-- UPDATE: и ещё материал по active inference: про внешнее-внутреннее и границу (и также системы неживые, живые и с интеллектом в этой связи. И системный подход и кибернетика в варианте Варелы-Матураны с их автопоэзисом, тут тоже по линии active inference нужно пересмотреть)
-- надо ещё поглядеть, что писалось у меня в блоге за последний год с момента прошлой переписки.
-- и, конечно, упражнения в онлайн-курс на моделирование в SysMoLan (таблички, скорее всего это будет сразу в coda.io)

Видео недавней панели по open-endedness: https://www.youtube.com/watch?v=hr_7SLG3GDA. Kenneth Stanley с другими исследователями ругают reinforcement learning и neural network, подчёркивают недоизученность алгоритмов эволюции и влияния мира такого, каков он есть (среды для агентов) на бесконечное развитие. Проблема не столько в отсутствии вычислительных ресурсов по сравнению с реальным миром и реальной эволюцией, но именно в непонимании алгоритмики эволюции и свойств вселенной, которая вдруг ухитрилась сделать эту эволюцию. А ещё появился интеллект, и сшиб все карты -- но важно понимать, что до интеллекта, до нейронных сетей с эволюцией всё тоже было в порядке, она происходила. Саму open-endedness Stanley понимает как continual generation of artifactics that are interesting to us without bound forever). При этом система сама должна учиться, ибо мы вряд ли сможем дать какой-то отклик на обстоятельства этой бесконечно развивающейся системы в ходе обучения, эти обстоятельства/проблемы же будут для нас новыми! А сама система тоже никогда не сможет адаптироваться и генерализовать описание мира существенно, ибо мир-то всё время новый! Проблема в том, что миры для open-endedness и алгоритмы сейчас небогаты, и мы не видим чего-то такого, чего мы бы не могли предвидеть (все эти "прятки агентов" и EnhancedPOET и прочие демонстрации). Но бесконечное развитие нам нужно как раз для того, чтобы появилось что-то такое, что мы не могли бы предвидеть! Stanley говорит, что мы вроде как вышли на плато с нынешними системами, и дело не в том, что у эволюции миллиарды лет, а текущие системы имеют очень небольшое вычислительное время, а в том, что эти системы выходят на "потолок в развитии". Все они там призывают иметь среды посложней и цели (в отличие от reinforcement learning с его наградами) поразнообразней. Environment design is basically like completely virgin territory, because no experts on this, no study, no theory, nobody knows anything about this.

Microsoft и NVIDIA натренировали языковую модель MT-NLG на 0.53 триллиона параметров (x3 по сравнению с подобными текущими моделями, прежде всего GPT-3 на 0.175 триллиона параметров). В этой сетке 105 слоёв на базе трансформер-архитектуры -- https://www.microsoft.com/en-us/research/blog/using-deepspeed-and-megatron-to-train-megatron-turing-nlg-530b-the-worlds-largest-and-most-powerful-generative-language-model/. Сетка, конечно, выдаёт SoTA по большинству моделей (zero-, one-, few-shot) в самых разных задачах, но текст содержит оговорки -- что там насколько улучшилось, не очень понятно. И, конечно, стандартные заявления про bias, суть которых сводится к "модель научена на знаниях человечества, а эти знания уже biased, и мы работаем над тем, как исправить эту проблему". Грубо говоря, "учиться на опыте человечества нельзя, а нужно заиметь опыт, которого у человечества ещё не было. Мы работаем над этим". Если поглядеть на то, что обсуждают ребята из абзаца наверху в части "предпочтение иметь решения, которые поднимают больше вопросов, чем дают ответов", и сравнить с тем, что пишет по поводу SoTA-ориентации в физике David Deutsch ("And let me add a methodological point: Framing research in terms of increasing a number, such as Q_plasma or Q_total, rewards incremental-type research and penalises more fundamental, idea-based research. If this problem is to be solved, it will be solved by ideas. Q will follow. Perhaps discontinuously. Perhaps going down before it goes up", https://twitter.com/DavidDeutschOxf/status/1445488874587758592), то становится понятно, что нужно ожидать чего-то более интересного, чем рост размеров языковой модели. Опять же, Pearl задаёт всё время вопрос, каким образом эти языковые модели хоть как-то помогают строить объяснения (вторая и тем более третья ступенька в causality ladder). Намёк в тексте, что эта сетка рассуждает чуть лучше, чем можно было бы от нейронной сетки ожидать, есть -- но претензии к языковым моделям на нейронных сетях отнюдь не в слабости их логики! Тем не менее, пока эти сетки -- самая умная нежить, которую смогло придумать человечество. В статье утверждается, что с ростом числа параметров качество моделей продолжает расти, и конца этому не видно, но вот этот "прирост качества" оказывается слишком количественным, и количество как-то не очень переходит пока в качество. Впрочем, никто не знает, куда эти огромные нейросетки придут "сбоку" и что они там драматически изменят.

Новое пришествие социализма в wokeism и cancel culture обсуждается через разницу слов equality и equity -- equality это равные шансы для всех, а equity -- это когда "каждому по потребностям". Вот восхитительная история про MIT, который запретил лекцию профессору, выступившему за приём в вуз на основании входных тестов (equality), а надо-то по квотам для разных меньшинств -- кто поглупее оказался, так тех и принимать (equity), вот: https://www.dailymail.co.uk/news/article-10079719/Thousands-register-remote-lecture-Princeton-MIT-axed-outraging-Twitter-mob.html. И красивая картинка от социалистов, чтобы вы не ошиблись в выборе, "голосуйте сердцем!":


UPDATE: дискуссия в https://www.facebook.com/ailevenchuk/posts/10221828366952412
2021 год

Coda.io -- куда они движутся, и как мы это используем

Coda.io провело конференцию, где тамошний CEO Shishir Mehrotra выступил с несколькими интересными заявлениями (https://www.youtube.com/watch?v=uxLpLlyrqhM):
-- меняют coda.io с "платформы документов" на "платформу ритуалов"
-- они выкатывают новую экосистему коннекторов в разный другой софт (и до кучи 1млн. долларов, чтобы там побыстрее что-то появилось)
-- они выкатывают редактор, поддерживающий вёрстку и редактирование одновременно

Документы в coda.io содержат формулы/программы, кнопки для исполнения программ (включая автоматическое исполнение как в случае формул электронных таблиц), структуры баз данных (табличные/реляционные) плюс сами данные, как структурированные, так и неструктурированные (грубо говоря, таблички и текст). Так что это вполне себе софт, технология -- особенно если понимать, что документы поддерживают в том числе и шаблоны как структуры данных и вычисления, поддерживающие практики. А вот практики -- это то, что выполняют люди по какой-то дисциплине, используя поддерживающие эту дисциплину технологии. И в coda если технологии -- это шаблоны, то практики -- это ритуалы. Заявление в том, что coda из платформы для технологий становится платформой для практик, то есть из платформы для нежити coda становится платформой для людей.

Templates -- это community templates в adaptive case management, ритуалы -- это какие-то куски кейсов, которые понятно как делать, "процессы внутри кейсов". А вот документ поддерживает кейс в целом. В документе есть есть заполняемые по ходу дела части (case file) и "ритуальные" части, которые поддерживают процессы. Но в целом и весь документ с ритуалами внутри поддерживает какую-то практику, а не просто описывает какую-то систему.

Вот тут coda.io на распутье: с одной стороны, речь идёт об универсальной вычислительной платформе, универсальном моделере. Но с другой стороны, объявление платформой ритуалов делает coda.io платформой для case management, где шаблоны документов поддерживают практики, а экземпляры применения этих шаблонов -- работы.

Как я к этому отношусь? Для меня coda.io -- универсальная вычислительная платформа, но поскольку у меня есть мета-мета-модель, то мне понятны мета-модели всех этих "ритуалов", "управления задачами", "систем управления знаниями" и knowledge hubs, которые по сути попытка людей в coda.io сказать "корпоративная информационная система", но языком не программистским, а человеческим. Так сказать, single source of truth и прочее, что говорят менеджеры, а не программисты. Это похвально: иметь мощную универсальную систему программирования, но пытаться говорить о ней с точки зрения функциональности корпоративных информационных систем, этих самых knowledge hubs. Вот тут пример парочки таких систем https://www.youtube.com/watch?v=WiobuZ5oUhY (хотя в начале много бла-бла-бла про важность и чистого маркетинга, но в середине демонстрируют шаблоны документов, и ещё эти шаблоны есть для отдельного просмотра -- эдакий хелпдеск knowledge management фирмы Webflow https://coda.io/@anna-k/coda-knowledge-base-template и система целеполагания для продуктов в PandaDoc https://coda.io/@ilyapandadoc/central-product-station). Вот тут больше примеров в видеоканале: https://www.youtube.com/c/Coda_hq/videos

Как понять, о каких "строительных блоках" идёт речь: вот тут небольшой видеокурс, просто смотрите кино подряд, там всё понятно, и материала не слишком много -- https://www.youtube.com/playlist?list=PLcQRHmSuAAiq-GXGIQk7lOZEnbb3bWZhX

А поскольку речь идёт о платформе для корпоративных информационных систем и звучат традиционные для PLM слова про single source of truth, то немедленно поднимается следующий вопрос: а насколько вы готовы лезть в другие информационные системы? Ибо все такие инициативы заканчивались обычно плохо ровно в этой части: нет коннекторов/адаптеров/плагинов, а в coda.io это называют паками. Pack -- это коннектор, который представлен в документах в виде набора (пакета, отсюда и имя) так называемых "строительных блоков" для вёрстки документов. Это таблички (которые будут с данными), кнопки для действий над данными, типовые обработки и фильтры и так далее. До сих пор coda.io была "как все", то есть предоставляла музыку (spotify) и какой-нибудь GitLab бесплатно, а вот ещё некоторое количество коннекторов (например, какой-нибудь GitHub) в премиальных тарифах. Дальше интересно:
-- явно не прозвучало, но поскольку coda.io это платформа для самых разных ритуалов, и именно она будет "порталом", то принята модель операционной среды/системы
-- и софтами в этой операционной системе будут другие корпоративные информационные системы, доступные через паки. Установка какой-нибудь вашей CRM в coda.io -- это установка pack для этой CRM.
-- а поскольку pack это не API, то можно сразу обычным образом верстать приложения/документы, то есть поддерживать практики и их ритуалы с использованием всех данных (и в недалёком будущем действий, с этим пока проблемы), доступных через packs.
-- дальше слушаем историю, как централизованная поставка контента всегда сменяется децентрализованной (типа как социальные сети типа тиктока и ютьюба вытесняют киностудии в части времени, которое люди тратят на них, а не на старые централизованные модели с "качественным контентом от редакций и студий"). И про софт говорится то же самое: в руки пользователей отдаётся самостоятельное изготовление packs для всего, что шевелится. Люди получают Packs SDK, и coda.io тем самым получается супер-дупер интегратором корпоративных информационных систем, "единым источником корпоративной правды".

И вишенка на торте, но важная вишенка. Проблема в том, что корпоративный софт должен быть:
а) похож на Excel или базу данных, то есть это должен быть табличный процессор.
б) похож на Word, ибо часто нужен текст, документация
в) похож в вёрстке на приложение или ещё хуже, PowerPoint, то есть должен радовать глаз менеджера.

В жизни это три типа софта, новый редактор для coda.io совмещает все три в одном (и приводится несколько тестов -- что там с перемещением курсора, что там с выделением текста в разных верстальных блоках и т.д.. При этом они говорят про два типа софта, ибо таблица у них -- это такой специальный текст, а не произвольная вёрстка из блоков на странице). А поскольку мы понимаем, что там каждый "строительный блок" включает в себя какие-то формулы, то это вполне попадает под понятие "вёрстки программ", к которому всегда стремился Alan Kay. Ну, у Alan Kay там подразумевался "настоящий язык программирования", а тут "язык формул" и в Pack как я понял, будет JavaScript, тем не менее (вот тут я писал про Codia как Coda+Julia для примера, при всём понимании, что языки формул и языки программирования -- они про разное, и сложность у них разная и вообще всё разное: https://ailev.livejournal.com/1580041.html. Сказка там полная ложь, но в ней намёк!).

Для меня это всё вполне убедительно. Это вовсе не значит, что у coda.io не будет конкурентов! Конечно, всё будет! Но шаги, которые они там делают -- они абсолютно понятны, для меня это всё вполне логичные способы бороться с давно известными проблемами. Дальше там появится нужда в какой-то концептуальной схеме, когда замучаются с этими паками, но это уже не в этой жизни. Дальше столкнутся с тем, что "что в моём документе объект, в твоём атрибут -- и как жить?", но это тоже не в этой жизни. Онтологическая интеграция данных жизненного цикла для инженерных систем -- это, конечно, не для coda.io. Браузер деревьев там примитивный (документы да страницы, "книжка с навёрстанными приложениями"). Примитивно всё. Но именно эта примитивность даст шанс распространиться, ибо все эти навороты в решении понятных проблем практика показала -- не работают! Интегрируют всё одно "точка-точка", и данные хранят в реляционках (или каких-нибудь более примитивных графовых хранилищах), а не в трипл-сторах. Графы и в coda.io добавят, куда ж они денутся. Подождите пару-тройку лет.

Как я это всё использую? Моделирую. Вот, например, как я использовал условное форматирование для примера покрытия интеллект-стека курсами ШСМ, который дал в https://ailev.livejournal.com/1586432.html. Основа этой модели -- разделение образовательного стандарта (чему учим, методологическая работа) и учебных курсов (как учим -- в какой последовательности, сколько раз повторяем один и тот же материал в разных курсах, на каком уровне учим). Я добавил ещё несколько наших курсов в табличку (хотя точность там никакая, но всё-таки), а затем применил "условное форматирование": если "всего по Школе" меньше 50, то подсветка красная, если больше 100, подсветка зелёная, если от 50 до 100 -- всё оставить цвета фона (тёмная тема, фон чёрный). Дальше моя работа как научного руководителя: решить проблему с красным цветом, довести его хотя бы до чёрного! Потом увести всё в зелёный (и добиться, чтобы "зелёный" соответствовал 300, то есть трём предъявлениям содержания образования в разных курсовых контекстах). Понятно, что сами измерения "чему планируем научить" (а потом и "чему по факту научили") должны быть точнее, но лиха беда начало. В ШСМ схема уже обсуждается, и на её основе формируем наши планы работы (уж свой план работ я точно делаю, пялясь на эту схему. Но и другие преподы понимают, что им нужно делать то же самое -- у них просто другая детализация практик, и сами курсы состоят из модулей. Но принцип-то тот же! Важно, что содержание образования и курсы тут разделены). Вот:


Так что я буду использовать coda.io просто как моделер SysMoLan, который выдаёт модели презентационного качества. Так сказать, для "модели продукта". Но мы, конечно, в ШСМ будем использовать и как софт корпоративной информационной системы, для "модели проекта", для нашей PLM.
2021 год

lytdybr

Продолжаю писать ОдО, и там всё медленно (примерно 300 вордовых страниц переписано из 400). При этом предыдущая версия книги даже наносит людям непоправимую пользу, что убеждает меня в необходимости таки писать, не останавливаться (пример пользы: мемуар Даниеля Корнева https://danielko.medium.com/musings-of-tech-space-enthusiast-part-i-428c28655b44 и https://danielko.medium.com/musings-of-ai-space-enthusiast-part-ii-840c6b36973d, общий смысл там в том, что не нужно настаивать на удерживании какой-то рано прихваченной мечты. Чтобы быть современным, нужно и мечту регулярно менять! И не чувствовать вины за то, не удерживаешь мечту во что бы то ни стало -- это ты просто не хочешь во что бы то ни стало быть старомодным, нужно гордиться тем, что меняешь мечту и остаёшься современным, а не стыдиться этого). Но новая книжка получается ни разу не попсовой. Попсовое там только первая часть, но и в ней я не уверен. Эту книжку хорошо будет читать нашим выпускникам (ну, или листать тем людям, которые хотят подглядеть, о чём могут думать наши выпускники).

Перепостил сообщение о том, что в Красноярске активистку штаба Навального будут судить за использование восклицательного знака в её постах в инстаграм: «Семиотические доминанты исследуемого символа отражают связь с фамилией Алексея Навального, также возможно установление примерного смыслового содержания, заложенного в символ ❗» говорится в материалах дела, и я приписал к этому посту басню Крылова про "ты виноват уж тем, что хочется мне кушать", полный текст как раз отражает суть дела -- https://www.facebook.com/ailevenchuk/posts/10221741429419028.

Провели большое заседание по ритмике в мультидансе, результаты изложил в https://vk.com/wall-179019873_1342. Я не очень понимаю, кто может поддерживать разговор на эту тему в полном объёме: там затрагивается и 4D экстенсионализм в части паттернов во времени, и predictive coding с active inference как модель восприятия ритмики (в том числе музыки и танца), многошкальная и многопоточная модель управления вниманием, проблемы полиритмии и сочетания воспринимаемых (музыка) и производимых (танец) ритмов, онтологические проблемы (мета-мета-модель стека ритмических практик и мета-модель "музыкальности в танце"), различие методологии и методики в обучении ритмике, отличие круговых ритмических диаграмм как визуальной ритмической нотации и такадими как попытка выхода на текстовую нотацию (вместо использования только в сольмизации -- "пропевания" ритмов, ритмического сольфеджио). Как всегда, на примере танцев я хочу выйти на общие мысли о ритмике и паттернировании во времени.

Matthew West мало того, что получил недавно орден за свои онтологические работы, так сегодня ещё и получил награду за участие в работах по стандартизации ISO TC 184/SC4 - Industrial Data (в том числе выпуск ISO 15926). ЖЖ мне напомнил про очень любопытный мой текст от 26 сентября 2007 года про 3D и 4D моделирование в строительстве, и там я задаю очень странные вопросы (по сути -- как уйти от слишком визуальных представлений, которые оказываются трудны в изготовлении), а в комментах впервые упоминаю ISO 15926 (ха, сегодня тем самым 14 лет со дня знакомства с этим стандартом и его 4D экстенсионализмом. Сколько ж всего пройдено в этом направлении за эти 14 лет!) -- https://ailev.livejournal.com/514438.html. Проблема есть, решение в отказе от визуальности (и 2D и далее 3D, и далее 4D) в плане задания форм и оставления визуальности в части наблюдения результирующих 3D (а не каких-то других, которые остаются табличными и текстовыми) форм -- это тренд и сегодня, и имя ему generative design (хотя имя и будет плыть со временем). Пишем (да ещё и не слишком формальную, на псевдокоде) текстовую модель, а потом смотрим нагенерированный по ней всяческий рендеринг.

Почему именно coda.io -- очень напоминает холивар про "лучший язык программирования", "лучшую операционную систему", "лучший тип микропроцессора", "лучший смартфон" -- бесперспективный разговор. Если у кого-то есть уже система моделирования, то и хорошо. Если у кого-то нет, то выбирайте. Я явно не амбассадор coda.io, но меня просто впечатляет количество успешных проектов более-менее сложного моделирования в этой среде по сравнению со многими другими средами. Ибо эта такая база данных с хорошим пользовательским интерфейсом (как написал у меня Михаил Гусаров в чате блога, "В прошлом году я искал «Microsoft Access, но в вебе». Вот, как раз оно", https://t.me/ailev_blog_discussion/10670). Вот ещё один разговор про coda.io и чем заменить (хотя наоборот, на мой взгляд именно coda.io всех сейчас заменяет -- это ж low code программирование над базами данных, хотя там и эксельность тоже явно просматривается, тоже ведь low code программирование). Вот ещё один разговор на ту же тему "что, неужели coda.io, неужели вы окончательно на неё переезжаете?!", но с выходом на PLM и организационное моделирование -- https://www.facebook.com/viacheslav.mizgulin/posts/4428569233863829. Я там даю "асимметричный ответ" -- привожу ссылку на сравнение систем корпоративного поиска, https://en.wikipedia.org/wiki/Comparison_of_enterprise_search_software, и говорю, что сравнивать по большому счёту нужно не notion.so, а вот этот весь зоопарк в таблице поисков с coda.io. Да, проблем в coda.io полно, но они потихоньку решаются, равно как решаются и в других системах, но ещё больше потихоньку. Надо брать, да делать. Это предпринимательское решение, мало кто может сказать, что будет с productivity tools через пять лет (средний срок жизни поколения софта).

Увидел ссылку на prompt engineering как на Software 3.0. Как-то это раньше прошло мимо меня (про prompt engineering я знал, про хлёсткое название Software 3.0 -- упустил), а термин гуляет ещё с весны (https://medium.com/nerd-for-tech/prompt-engineering-the-career-of-future-2fb93f90f117 и даже видео на 15 секунд об этом https://www.youtube.com/watch?v=O3zci5lW0WU, "Software 3.0 is Prompt Engineering". Обзорчик в https://arxiv.org/abs/2107.13586 -- "Pre-train, Prompt, and Predict: A Systematic Survey of Prompting Methods in Natural Language Processing"). Если написание программ методом градиентного спуска по Kartathy это Sotware 2.0, то написание "подсказки" для того, чтобы дальше смогла работать машинерия Software 2.0 -- это Software 3.0. Вот картинка из статьи:
2021 год

Алгоритмика

Информатика, её поддисциплины и её инженерная практика
Дэвид Дойч считает информатику/computer science (https://en.wikipedia.org/wiki/Computer_science) одной из четырёх нитей, без которых не получается объяснить структуру нашей реальности (другие – это квантовая физика в интерпретации Эверетта, эволюционная эпистемология Поппера, эволюционная теория репликаторов Докинза).

Иногда информатику делят (https://cstheory.stackexchange.com/questions/1521/origins-and-applications-of-theory-a-vs-theory-b) на Theory A как алгоритмику, занимающуюся вопросами сложности алгоритмов и их эффективностью, и Theory B, занимающуюся вопросами теории информации, семантики и логики вычислений.

В интеллект-стеке мы рассматриваем SoTA информатики как научной практики в разных местах стека. Более того, мы встречаем в интеллект-стеке информатику не только как научную дисциплину/science (теорию и средства моделирования для теории), но и как опирающуюся на её теорию инженерную практику в составе труда (компьютерную и программную инженерию как виды инженерии: создание компьютеров как физических вычислителей и программного обеспечения к ним). Грамотный человек сегодня не только умеет сам умеет читать сложный текст и писать слепым десятипальцевым методом на клавиатуре, но и может сам отмоделировать какой-то кусок мира, и даже сам выполнить какие-то несложные вычисления с помощью компьютера -- как предки с трудом научились умножать "в столбик", как дедушки-бабушки научились это делать при помощи калькулятора, так любой школьник должен уметь сделать это на каком-то языке программирования, хотя бы программируя на языке электронных таблиц MS Excel или Google Tables.

Понятие алгоритма как некоторой последовательности вычислений, из входных данных получающих выходные данные, все знают ещё из школы. Сегодня понятно (первый доклад в https://vimeo.com/553810189, слайды https://yadi.sk/i/F6e33aVANX3J3g), как алгоритмику в объёме требований по программированию из текущего ЕГЭ дать уже к окончанию начальной школы, причём детям на это требуется решать задачи всего около 16 часов (да, так мало!), а взрослым около 8 часов (они всё-таки более организованы, чем дети). Удивителен сам факт, что дети и взрослые осваивают азы мастерства императивного/процедурного программирования за примерно одинаковое время, а для этого достигают понимания основных понятий: алгоритма, вычислителя/интерпретатора алгоритма, языка программирования, программиста (составляющего алгоритм), шага алгоритма, данных. Эта учебная программа уже преподаётся десяткам тысяч детей.

Но всё-таки компьютеры в массе своей в труде используются только как ручка-бумажка-на-стероидах. Не "вычислитель" (computer -- это вычислитель!), а просто "счёты с хорошей коллективной памятью". Память при при этом, конечно, структурированная -- она содержит не просто какие-то тексты и картинки, а описания мира/модели, обширные "базы данных" с довольно кучерявыми "моделями данных". Или даже неструктурированную информацию для полнотекстового поиска в корпоративных хранилищах документов. Как устроены эти описания мира разной степени формальности в computer science разбирается в рамках Theory B (теория информации, логика, семантика, далее мы будем ещё рассматривать онтологию с многоуровневым мета-моделированием, они все идут по этой линии Theory B): как мы думаем о мире, как записываем наши мысли, что означают знаки, как представлены знаки на физических носителях, как их интерпретировать.

Выычислительная мощь компьютеров в бизнесе пока задействуется примерно в объёме бухгалтерских счётов-на-стероидах, простейшие сложения и умножения. Это вычисления человека, который использует компьютеры и компьютерную связь для помощи в управлении личным и коллективным вниманием, для организации общения с другими людьми, для умощнения памяти. Вычислять ничего не нужно, знание о том, как составить простой алгоритм и объяснить его компьютеру на языке программирования школьники получают, сдают ЕГЭ -- и дальше не используют.

Проблема в том, что в 21 веке алгоритмика (Theory A из computer science/информатики) поменялась, и нужно с ней разбираться заново.

Новая алгоритмика: изучение универсальных алгоритмов
В Theory A предметом заботы является алгоритмика, вычисления как таковые -- нахождение таких способов вычислений, которые как дают точный результат, так и укладываются в ресурсный бюджет. Проблема в том, что точность моделирования мира и потребность в вычислительных ресурсах в большинстве случаев увязаны между собой. Если вы хотите отмоделировать мир точно, то вам нужно много исходных данных и много вычислений. Иногда это удаётся обойти придумыванием нового способа моделирования, новых алгоритмов вычислений, но иногда теория говорит, что в общем случае это невозможно. Например, сегодня для многих и многих задач находится максимум какой-то функции методом градиентного спуска. В конце 2021 года выяснилось, что точность и вычислительная сложность (время вычисления) для таких задач связаны пропорционально . Если точность удвоить, то время нужно увеличить вчетверо (и это обычно приемлемо), но если для некоторых приложений нужна точность в квадрате, то время (число вычислительных шагов) нужно увеличивать тоже в квадрате – и это может оказаться за пределами разумного. Скажем, 1млрд шагов одинарной точности могут выполняться одну секунду, но вот миллиард секунд для квадрата этой точности – это 32 года работы вычислителя!

Похожие рассуждения по ресурсным (а не теоретическим!) ограничениям на вычисления есть и для многих других классов задач. Например, криптографические задачи основываются на том, что вы легко проверяете ключ на его правильность, за долю секунды. Но вот найти этот ключ, если вы его не знаете, может потребовать тысяч лет вычислений. Ситуация осложняется тем, что при переходе на другую физику (например, квантовый вычислитель/компьютер разбрасывает нужные для получения операции по бесконечному числу вселенных, а потом собирает их результаты для получения конечного ответа, подробно это рассказывается в книгах Дэвида Дойча) оценка сложности алгоритмов меняется. И ещё всё время придумываются новые алгоритмы, причём нахождение нового алгоритма – это творческий процесс, для многих классов задач до сих пор (2021) непонятно, можно ли вообще найти быстрый алгоритм получения решения (проблема перебора, https://ru.wikipedia.org/wiki/Равенство_классов_P_и_NP ): можно ли для задач, которые заведомо решаются методом перебора придумать алгоритм, который решает их не за экспоненциальное по отношению к объёму входных данных время, а за меньшее, полиномиальное или даже линейное. Алгоритмика до сих пор не даёт ответа на этот важный вопрос!).

Есть математический результат 1989 года (теорема Джоржа Цыбенко, https://ru.wikipedia.org/wiki/Теорема_Цыбенко ), который показывает, что нейронная сеть с одним скрытым слоем является универсальным аппроксиматором, то есть может отмоделировать с заданной точностью любую функцию, если в ней есть "достаточное количество нейронов". Любая функция -- это таки математически любая, например, "распознавание речи" это из входных бит огибающей сигнала на выходе аналого-цифрового преобразователя с сигнала микрофона вычислить по фукнции распознавания речи последовательность бит слов текста в подходящей символьной кодировке. Синтез речи -- это обратная функция, из букв в звуки. Диагноз -- это функция из входных данных множества анализов больного в выходные с текстом диагноза. Назначение лечения -- обратная функция.

Проблема только в том, что на существующих классических компьютерах моделирование даже простых функций занимает на такой нейронное сети огромное время, это математически очень крутой результат, но практически он бесполезен. Алгоритмика как раз наука о том, как получить практически полезные результаты. Так, если сделать глубокую нейронную сеть (несколько скрытых слоёв), то свойства универсального аппроксиматора остаются, но время моделирования оказывается вполне приемлемым -- хотя опыт показывает, что один расчёт по сегодняшним ценам может стоить несколько миллионов долларов за аренду вычислительных мощностей для этого (нейронная сеть GPT-3 была вычислена за примерно $4.6 миллиона долларов, а если на том же уровне цен обучать нейросеть GPT-4, то это обошлось бы в $8.6 миллиардов долларов, https://www.reddit.com/r/MachineLearning/comments/i49jf8/d_biggest_roadblock_in_making_gpt4_a_20_trillion/).

Интеллект компьютеров, похоже, зависит главным образом от вычислительной мощности -- это так называемый "горький урок" (http://incompleteideas.net/IncIdeas/BitterLesson.html), полученный анализом всех прошлых прорывов в области AI. Все эти прорывы оказывались прорывами не столько в хитрых конструкциях самого интеллекта как исполняемого на хитрых компьютерах хитрыми алгоритмами, сколько прорывами в не очень хитрой вычислительной мощности, которую отдавали относительно простым универсальным алгоритмам. То есть вы в конечном итоге терпите неудачу, когда пытаетесь сочинить сложный алгоритм, управляющий каким-нибудь автомобилем в поездке. Но если вы в автомобиль включаете суперкомпьютер, и этот суперкомпьютер выполняет относительно простые вычисления в нейросети, то вы получите такие результаты, какие не получите от специально разрабатываемого традиционного "алгоритма вождения автомобиля". Поэтому внимание исследователей искусственного интеллекта обращается к HPC, high performance computing и универсальным аппроксиматорам, вычисления с которыми ведутся на этих компьютерах.

Новые универсальные алгоритмы отличаются тем, что сами функции не программируются/моделируются/описываются вручную/аналитически, но познаются/выучиваются/learn/вычисляются компьютером при минимальном вмешательстве человека. Распознавание речи, изображений, поиск аномалий (тут нюанс: аномалия характеризуется тем, что нужно распознать не то, что компьютер уже видел, а наоборот -- то, чего он ещё не видел!) компьютер делает уже лучше, чем человек.

А алгоритмы творчества есть такие? Если вернуться к универсальным алгоритмам, которые работают с универсальными аппроксиматорами, могут ли они творить? Да, могут. Творчество идёт по тому же пути, что и эволюция: в шуме (например, шуме, получаемом при помощи генератора случайных чисел на тепловом шуме, чтобы надёжно этот шум был свободен от любых закономерностей) потенциально содержится всё новое, что может быть придумано в мире. И дальше можно просто модифицировать этот шум так, чтобы он попал под необходимые ограничения. Если немного поманипулировать со сжатием информации (схематизацией/моделированием) и последующим разжатием (демоделированием/рендерингом), то вычислительно это всё может быть вполне осмысленным. Если каждый алгоритм распознавания основывается на какой-то модели, сохраняющей знания о важном для распознавания аспекте входных сигналов, то можно всегда предложить алгоритм порождения, который в выходном сигнале сохранит это важное -- алгоритм распознавания признает творчески сгенерированный новый объект "своим". Алгоритм устроен примерно так: тренируют подалгоритм распознавания, и на вход ему подают шум от подалгоритма генератора -- распознаватель говорит "это не то" и сообщает генератору, что ему особо не понравилось. Генератор подстраивает свой выход, чтобы понравиться распознавателю -- и так много раз, пока ему не удаётся обмануть распознаватель. Если распознаватель умеет распознавать картины Ван Гога, то генератор в конце концов сумеет сделать картину, которую и человек и этот распознаватель (качество распознавателей сейчас уже не хуже, чем у людей) признают, как картину Ван Гога, но готовил эту картину не Ван Гог, а генератор. Это и есть алгоритмика: придумать такого сорта алгоритм!

В статье 2017 года "Software 2.0" (https://karpathy.medium.com/software-2-0-a64152b37c35) Andrej Kaprathy (сегодня он главный по искусственному интеллекту в Tesla) сделал пророчество, что при наличии достаточных вычислительных ресурсов качество алгоритма, которое даст оптимизация градиентным спуском (иногда это называют дифференцируемым программированием/differentiable programming, https://ailev.livejournal.com/1464563.html) будет выше качества алгоритма, которое разрабатывается программистами, и поэтому людям-программистам придётся заняться чем-нибудь ещё.

Уместна ли алгоритмика в интеллект-стеке?
Кому нужно знать про универсальные аппроксиматоры и алгоритмы, их реализующие? Нужно ли людям сегодня понимание того, как и зачем используются алгоритмы, какие они бывают, где используются вычисления по самым разным алгоритмам? Грубо говоря: нужна ли алгоритмика в интеллект-стеке?

Да, она нужна. Ибо мы не только запоминаем-вспоминаем информацию, но и как то над ней задумываемся, погружаемся в размышления/вычисления, которые требуют ресурсов. По большому счёту, вычисления нужны для:
-- познания/исследований: создание объяснительных моделей на основе восприятия окружающего мира и учёта уже имеющихся объяснений
-- деятельности на нескольких системных уровнях: в цикле/динамике вычисление/инференс/вывод/апдейт предсказаний по имеющимся моделям на основе восприятия/внешних данных, планирование действий, которые приведут предсказания к нас устраивающим, и действия/выполнение плана/актуация

Познание как построение всё более и более мощных объяснений/описаний/моделей мира, дающих всё более и более точные предсказания и деятельность по изменению мира в сторону благоприятных для нас предсказаний по имеющимся объяснениям -- это и есть жизнь.

Это всё не очень ново, так как в такой общей постановке вопроса не отличается от классических задач той области computer science, которая называлась artificial intelligence и занималась поиском решения отдельных проблем, имеющих большую вычислительную сложность, и поэтому не подвластную старым компьютерам: это как раз задачи представления знаний (моделирования/познания мира, и тут мы опять попадаем в семантику и логику), а также задачи планирования. Про человеческий "интеллект" говорили, но это всегда казалось далёкой целью. Почему же это была отдельная область знаний от всей остальной информатики? Потому как решения этих задач в общем виде никак не давалось алгоритмизировать, получающиеся в результате расчёта модели и планы были хуже тех, которые готовил человек. А сейчас за очень дорого (для самых интересных приложений это миллионы долларов за один расчёт, а этих расчётов нужно много!) модели и планы начинают быть лучше тех, которые могли бы приготовить люди.

Прежде всего это относится к таким расчётам, которые делаются для предобучения глубоких нейронных сетей, это лучшие универсальные аппроксиматоры (напомним, что речь идёт о свойстве с какой-то заданной точностью аппроксимировать любую функцию как преобразования из входных данных в выходные, под это можно подогнать практически любую задачу). Алгоритмы глубокого обучения -- это первый обнаруженный людьми класс алгоритмов, который показал удивительную особенность: качество полученных моделей растёт при добавлении вычислительных ресурсов. Уточнение решений для этих алгоритмов заканчивается не потому, что уже ничего там улучшить не удастся, сколько не вычисляй, а просто потому, что слишком дорого вычислять. Было бы дешевле, получили бы решение получше! Это очень, очень дорогие на сегодняшний день расчёты, их цена падает с годами экспоненциально, но и потребность в них растёт экспоненциально, потому как если потратить столько же денег завтра, сколько тратим сегодня, закупив на эту же сумму побольше вычислений, то получим результаты лучше! Этот класс алгоритмов был придуман в 1987 году, но другие алгоритмы этот класс алгоритмов смог обогнать только тогда, когда было использовано компьютерное "железо", особо подходящее под эти алгоритмы (GPU, https://towardsdatascience.com/what-is-a-gpu-and-do-you-need-one-in-deep-learning-718b9597aa0d), на обычных компьютерах эти алгоритмы не работают, ибо не хватает вычислительной мощности.

Отвлекаясь от конкретных алгоритмов решения вычислительных задач, где сегодня используется компьютерная мощь, именно вычисления, где можно подглядеть то будущее, которое нас ждёт при реализации тренда экспоненциального падения стоимости вычислительных ресурсов?

Получается такой разрыв: понимание, почему вычисления такие дорогие, и как их сделать дешевле -- это предмет алгоритмики, которая находится довольно низко по интеллект-стеку. А использование этого понимания должно быть в бизнесе. Вот идём в бизнес. Квантовые компьютеры обещают дать нам невиданную вычислительную мощность, которая явно избыточна для тех, кому компьютеры нужны как ручка-бумажка-на-стероидах. Кто уже сегодня интересуется квантовыми компьютерами, для каких расчётов будут использовать их головокружительные вычислительные возможности? Если посмотрим на разные предложения по использованию (https://www.idquantique.com/quantum-safe-security/quantum-computing/real-world-applications/, https://hbr.org/2021/07/quantum-computing-is-coming-what-can-it-do, https://builtin.com/hardware/quantum-computing-applications), то заметим там примеры того, о чём мы тут писали, наши догадки верны:
-- создание объяснительных теорий в естественных науках (физика, метеорология, химия, биология и медицина, криптография)
-- предсказания и обновления предсказаний (инженерия, медицина, трейдинг, компьютерная безопасность -- смотри все те прикладные практики, которые задействуют объяснительные теории из естественных наук)
-- планирование (всё те же прикладные практики, которые задействуют предсказания из предыдущего пункта)

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

Как отследить тренд на вычислительные модели в которых существенно задействована алгоритмика, а не просто использование компьютеров для накопления данных и их красивого показа? Цифровой двойник/digital twin как понятие сегодня быстро размывается в значении, но всё-таки его создание подразумевает создание какой-то модели физического двойника на стадии и эксплуатации тоже, для того, чтобы иметь предсказания и предупреждения (вот тут вычисления!) по поводу состояния физического двойника по состоянию отмоделированного цифрового двойника (https://ailev.livejournal.com/1546514.html, https://ailev.livejournal.com/1570630.html). На сегодняшний день в инженерии принимаются решения на основе традиционных алгоритмов физического моделирования, базирующихся на вручную составляемых людьми системах дифференциальных уравнений, которые потом решает компьютер (https://ailev.livejournal.com/1549559.html). Но и тут работает тот же тренд: физическое моделирование на универсальных аппроксиматорах оказывается надёжней, цифровые двойники тоже переходят на использование универсальных алгоритмов моделирования, сегодня это прежде всего алгоритмы на глубоких нейронных сетях.

А пока квантовых и иных с "новой физикой" дешёвых и мощных компьютеров нет, новые универсальные алгоритмы вычисляются на "обычных" компьютерах с кремниевыми чипами как центральных процессоров (CPU), так и ускорителей вычислений на базе GPU.

Как и где эти алгоритмы применяются? Как и естественный интеллект: везде, в самых неожиданных местах, которые только можно придумать!

Например, алгоритм NVIDIA на основе глубоких нейронных сетей сокращает требуемый для видеоконференций трафик вдесятеро, https://syncedreview.com/2020/12/02/nvidia-neural-talking-head-synthesis-makes-video-conferencing-10x-more-bandwidth-efficient/. Если вы занимаетесь видеоконференциями, и не знаете об этом прогрессе в алгоритмике, то вы покинете рынок. Главная тут мысль -- такое происходит сегодня повсеместно, универсальные алгоритмы появляются в самых неожиданных местах и дают самые неожиданные результаты. Если вы не знаете, как про эти алгоритмы говорить, сколько они стоят, как и кто их разрабатывает, отслеживают ли их появление айтишники вашей фирмы -- вашей фирме не жить. Алгоритмика важна. Первая волна компьютеризации "управления коллективным вниманием" в фирмах быстро переходит во вторую волну, где компьютер берёт на себя часть мышления/вычислений в двух ситуациях:
-- слишком дорого заказывать эти вычисления людям. Так, миллиарды переводов с самых разных одних естественных языков на самые разные другие, которые делают за сутки автоматические переводчики Гугля, Фейсбука, Яндекса и других технических гигантов, просто не были бы выполнены. Да, они пока ужасного качества, на уровне десятиклассника, едва знакомого с языком, но они есть -- и не были бы выполнены, если бы нужно было обращаться к людям. Переводчики не потеряли работу, но часть работы взяли на себя алгоритмы
-- алгоритмы выполняют работу, которая раньше людям была недоступна. Законы Кеплера компьютер уже может переоткрыть из данных наблюдения за планетой (https://arxiv.org/abs/2011.11981). А фирма Сони не стесняясь говорит о создании компьютера-учёного, которому выдадут нобелевскую премию, что ожидается к 2050 году, https://www.engadget.com/sonys-head-of-ai-research-wants-to-build-robots-that-can-win-a-nobel-prize-180059012.html. Это всё алгоритмика, эти алгоритмы нужно создать, и эти алгоритмы нужно использовать.

Куда развивается алгоритмика в части развития универсальных алгоритмов?
В этой универсальности нейросетей не хватает сегодня:
-- предсказания нейронных сетей, равно как их творечство необъяснимы на сегодняшний день. Этой проблемой занимаются, какие-то успехи тут уже есть. Нам нужно не просто аппроксимирование какой-то функции, нам нужно ещё и объяснение ситуации, объяснение решения!
-- выход из чисто вычислительной работы в реальность, то есть восприятие и актуация (extended/embodied cognition).
-- осознанности, которую связывают в том числе и с возможностью строить длинные цепочки рассуждений по поводу рассуждений (алгоритм выбора алгоритма, алгоритм управления вниманием как выделением ресурсов для вычислений)

Есть много разных подклассов универсальных алгоритмов. Об этой погоне за универсальностью, за Master Algorithm рассказывает книжка Pedro Domingos, но она выпущена аж в 2015 году, это уже хорошее историческое введение, за шесть прошедших лет в алгоритмике много чего произошло нового (и продолжает происходить со скоростью два прорыва в неделю, https://syncedreview.com/). Сейчас нужно было бы писать новую книгу, примерно той же направленности, но дополненную новыми знаниями, полученными за последние шесть лет.

Например, учёные из DeepMind заявили (https://www.sciencedirect.com/science/article/pii/S0004370221000862), что настоящую универсальность дают алгоритмы reinforcement learning, в которых алгоритм "дрессируется" как животное: за достижение цели (или хотя бы приближение к цели) выдаётся награда. Тут же развязалась широкая дискуссия о том, что никакой особо универсальности от этих алгоритмов ждать не приходится, ибо типичная ситуация в том, что мы избегаем неприятностей/выживаем, при этом понятия не имеем, что такое "награда" или даже какого сорта могут встретиться "неприятности". Интеллект сам выбирает, что у него награда, ибо осознанность включает в себя и свободу выбора! Эволюционные алгоритмы -- с ними всё в порядке насчёт универсальности (человека-то они сделали!), но для них никогда не хватит вычислительных ресурсов. Чтобы сделать человека, вся Земля несколько миллиардов лет была эдаким вычислителем! Ещё одна заявка на "безнаградные" алгоритмы -- это отсылка к понятиям predictive coding, active inference, а вместо "награды" агенты с такими алгоритмами стремятся к минимизации свободной энергии/free energy principle (помним, что "энергия" эта не из физики, а из математики для физики, как и "энтропия" в теории информации). Алгоритмы этого подхода (чаще всего его называют active inference, больше информации можно найти в общественной организации, координирующей самых разных исследователей этого класса алгоритма, Active Inference Lab/ActInfLab, https://www.activeinference.org/), крайне элегантны (кратки и универсальны), но пока не продемонстрировали каких-то впечатляющих практических результатов по сравнению с другими видами универсальных алгоритмов. Алгоритмы формального логического вывода (раньше это называли "экспертные системы", потом "системы представления знаний", теперь самый распространённый термин -- knowledge graphs) показали, что они сами по себе работают плохо, их неудача повлекла так называемую "зиму искусственного интеллекта", когда науку универсальных алгоритмов практически перестали финансировать, вплоть до 2012 года, когда обратили внимание на глубокое обучение. И так далее, по многим и многим классам претендующих на универсальность алгоритмов. И при этом работает теорема бесплатного обеда: что универсально для какого-то класса задач, будет ужасно для другого. Хотите решения для многих разных классов проблем -- имейте много разных алгоритмов, выполняющихся на вычислителях с разной физикой! Так что "самый универсальный алгоритм" будет, скорее всего, каким-то сочетанием идей изо всех этих подходов.

Алгоритмика не только про способы вычислений на компьютерах, она и про способы мышления людей!
Но это всё разнообразие подходов к универсальности вычислений и дороговизна универсальных расчётов не снимает факта, что люди перестают заниматься алгоритмикой как придумывание людьми специальных алгоритмов для отдельных частных прикладных вычислений и больше внимания уделяют универсальным алгоритмам, а уж прикладные вычисления потом делаются по итогам работы универсальных вычислителей. Классическая алгоритмика, конечно, останется (программирование самих универсальных вычислителей включает и классическую алгоритмику), но акценты меняются буквально на глазах: алгоритмика 2016 года и 2021 года существенно разная. Так, архитектура универсального алгоритма Transformer была опубликована в 2017 году впервые, https://arxiv.org/abs/1706.03762, её просто не существовало в 2015 году (году публикации книги Педро Домингоса), но сейчас она по факту основная архитектура для всех универсальных алгоритмов, большинство практических применений следует идеям этой архитектуры и её модификаций. Ограничения такой архитектуры тоже уже хорошо известны, поэтому активно идёт поиск новых и новых универсальных алгоритмов -- более универсальных, более скоростных, менее требовательных к памяти. В 2026 году будут уже вполне в ходу квантовые компьютеры, но есть и аналогово-фотонные идеи (https://scitechdaily.com/novel-nanophotonic-analog-processor-developed-for-high-performance-computing/), и множество других аппаратных идей, так что и алгоритмика будет для них другой: сложность алгоритмов существенно зависит от физики вычислителя, что трудно для одного вычислителя, то нетрудно и быстро для другого.

Компьютерные вычисления и человеческое мышление одинаковы в том смысле, что это вычисления. Физику нашего "мокрого вычислителя" в голове мы тоже ведь дополняем "ускорителями" в виде разных компьютеров, так что они не только одинаковы, но и по большей части неразделимы. Весь этот наш подход "образования для образованных" через предобучение универсального интеллекта на основе интеллект-стека из фундаментальных трансдисциплин -- это такой же сдвиг от человека как "опытного" в части владения многими-многими прикладными специализированными алгоритмами решения отдельных прикладных задач к "умному", который способен справиться с самыми разными проблемами при помощи своего универсального интеллекта. Хотя по классификации Chollet -- ещё не универсального для всех классов проблем во вселенной, но всё-таки уже "экстремального" интеллекта, в отличие от текущего компьютерного интеллекта. Ход тот же самый, что и в современной алгоритмике: один и тот же универсальный аппроксиматор, задействуемый для решения самых разных проблем.

Люди тоже всё меньше будут просто "помнить и проверять, узнавать и передавать" (линейные менеджеры, передающие указания от топ-менеджеров персоналу, и собирающие отчёты по работе персонала, становятся не нужны, равно как не нужны и прочие клерки), но больше думать/рассуждать -- и плохо или хорошо это будет происходить тоже будет определяться способом их мышления, алгоритмами. Трансдисциплины интеллект-стека описывают лучшие известные человечеству способы мышления/алгоритмы мышления/последовательности действий, которые нужно выполнить интеллекту, чтобы решить проблему.

В интеллект-стеке нужна алгоритмика как мыслительная практика рассуждений о вычислениях/мышлении в той части, как рационально расходовать свой человеческий вычислительный ресурс, а также ресурс вычислительной техники. Мышление людей дорого, мышление компьютеров тоже дорого. Через некоторое время окажется, что самые дорогие, самые умные люди озадачивают самые дорогие компьютеры (и озадачить эти компьютеры помогают не менее дорогие компьютеры!), и хорошо бы, чтобы эти люди понимали, что способ вычисления/алгоритм имеет значение!
2021 год

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

Системное моделирование предприятия: чем сегодня стал 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. А ещё нужно иметь моделер для вот этого "текстокодового" моделирования.

Тем самым язык системного моделирования SysMoLan оказался "текстокодом" с несколькими уровнями мета-моделирования, которые находятся просто в голове наших выпускников, а на предприятии оказывается просто что-то типа "базы данных", только кроме таблиц включающей ещё тексты и аутлайны -- эдакая богатая среда для представления данных. По сути, гибрид экселя, реляционной базы данных, аутлайнера и текстового редактора. И ещё с внешними интеграциями, API для того, чтобы прицепиться к структурам данных внешних систем.

Среда моделирования для 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
2021 год

lytdybr

Переписан 51% ОдО, раскрываю новый интеллект стек как нарративизацию клубка трансдисциплин мыслительных практик. Как понять предыдущую фразу? Вот краткая разъяснялка, которую я даю на почти сотне страниц:
-- нарративизация это обычный термин, означающий вытягивание описания сложной ситуации как клубка каких-то идей и сложно связанной сети событий в последовательное изложение
-- трансдисциплина это работа с объектами внимания, которые определяются на прикладном/проектном уровне. Например, рассуждения по правилам используются при рассуждениях в самых разных ситуациях, поэтому логику относим к трансдисциплинам. Системное мышление тоже трансдисциплина, в самых разных ситуациях мы обращаемся к системному мышлению, чтобы взять оттуда системы, с которыми мы работаем в прикладных практиках.
-- мыслительные практики состоят из мыслительных трансдисциплин и инструментария их поддержки (в случае трансдисциплин инструментарий -- это разные моделеры, задействование внешних по отношению к мыслящему агенту человеку)
-- мыслительный -- это относящийся к мышлению как функции интеллекта
-- интеллект -- это мыслительное мастерство (синоним), использующееся для познания как выработке какого-то мастерства (прикладного или мыслительного, то есть основанного на прикладной дисциплине, или трансдисциплине)
-- интеллект-стек тут понимается как список трансдисциплин, нарративизированный по принципу минимального задействования нижними дисциплинами верхних в стеке (по мотивам модульных/платформенных стеков в системном мышлении). Скажем, онтология не особо нуждается в своих объяснениях в системном мышлении, а вот системное мышление существенно задействует в своих объяснениях знание онтологии. Но в целом трансдисциплины/объяснения существенно переплетены, и их нарративизация в виде стека весьма условна, нужна главным образом для учебных целей.

Начали присваивать квалификации выпускникам Школы (https://system-school.ru/), это делается для 989 человек, которые на сегодня закончили у нас хотя бы какой-то курс (при этом многие закончили несколько курсов). Тех, кто начал и не закончил (а их хватает), мы пока не учитываем.

Реакция на мои посты про компьютерную революцию (особенно на последний пост про OpenAI Codex, https://ailev.livejournal.com/1578279.html) вполне предсказуема и описана в самом посте, это пока стадия "отрицание" (потом будут стадии гнева, торга, депрессии и только затем спокойное принятие). Претензия сразу на то, что AI не заменит живого программиста (откуда такая постановка вопроса? Речь идёт просто о REPL на естественном языке! И тут вдруг "компилятор не заменит живого программиста, ибо не сможет поговорить с заказчиком". Что у людей в головах?!). Вообще, я уже писал, что AI сегодня понимается исключительно как superhuman AGI (и требуются доказательства! и один должен сработать за целую команду исключительно талантливых людей!), но жизнь устроена по-другому: AI будет работать на довольно узких классах задач на уровне восьмиклассника или первокурсника, но стоить это будет копейки. Дальше как с гуглепереводчиком: переводы там ужасного качества (но оно растёт!), но по факту бесплатны, и либо они не будут вообще сделаны из-за невыгодности оплаты услуг переводчика, несвоевременности перевода, отсутствия переводчика для какой-то пары языков и т.д., либо они ужасного качества, но бесплатны и есть. Поэтому использование -- миллиард запросов в день (не помню точно цифру, но порядок такой), и ни одного доброго слова по поводу сервиса, он же ужасен! Так будет и с GitHub Copilot (одно из приложений OpenAI Codex): миллиарды использований в день, и ни одного доброго слова, он же ужасен! Ибо будет использоваться там, где это экономически выгодно, а не где ему разрешат комментаторы из соцсетей: оценка их всегда будет негативной, даже если это будет образцовый код, они ж найдут к чему придраться! То, что качество этого кода они уже приравнивают к качеству кода быдлокодеров из далёких южных стран, они не замечают -- но нежить стоит дешевле быдлокодеров. Фронт же работ бесконечно растёт по мере уменьшения стоимости выполнения работ. Будет сгенерировано удивительное количество удивительно плохого кода. Дальше вопрос: что, лучше бы этот код не был сгенерирован? "Отберите у них хлеб, накормите их пирожными от лучших кондитеров!" -- так, что ли? Да ещё и с использованием недоопределённых суждений со словами "интеллект", "мышление", "понимание", значение этих слов можно ж быстро подкручивать по мере выхода новых версий Codex и подобных систем, которых появится довольно много и которые будут уметь с каждой версией всё больше и больше, как и гуглепереводчик. Нет, жизнь устроена по-другому. Вот вам ещё парочку видео того, что умеет Codex в его пока ещё private beta (это ещё даже не production вариант!):
-- как решаются задачи data science с использованием естественноязыкового REPL, https://www.youtube.com/watch?v=Ru5fQZ714x8
-- как решаются задачки для первого класса начальной школы в оригинальных их формулировках, если их задать прямо в REPL https://www.youtube.com/watch?v=fRyTycXMlzA

За пять дней мой перепост высказывания про транс-вакцинированных (https://www.facebook.com/ailevenchuk/posts/10221512211568725) получил в фейсбуке 125 лайков: "Транс-вакцинированными (transvax) следует считать людей, которые воспринимают своё тело вакцинированным, вне зависимости от того, проходили они вакцинацию или нет. Им нет нужды как-то дополнительно доказывать или обосновывать свою вакцинированность, достаточно внутренне ощущать себя привитым". До этого высказывания лучшим аналогом было рассуждение про биологический возраст: если пол можно почувствовать и заставить окружающих признать твои ощущения за правду, то что делать людям, которые чувствуют себя помоложе и постарше своих биологических лет?! С возрастом-то не меньше чем с полом в жизни всего связано, что не ты выбираешь, а тебе вменяют административно! Как и неожиданно с вакцинацией. Меня это всегда веселило: наркотики нельзя, а табак и алкоголь можно. Затем и табак почти нельзя, и алкоголь под строгим учётом, но алкоголь всё равно можно. Но всё остальное нельзя, хотя иногда уже можно! Так и тут: сначала разделяем пол и гендер, потом считаем, что после этого трюка ощущать себя кем-то иным по сравнению с полом уже можно официально, ибо ощущается гендер. Выход на олимпийские игры по гендеру, или по полу? По гендеру, и тяжёлоатлет-мужчина выступает среди женщин. А рожать? По полу, мужчины по паспорту берут и рожают (природе-то не запретишь работать!), дальше проблемы только у бюрократов, у которых в графе "мать" оказывается человек мужского гендера! А раса биологична? Трюк с гендером уже предлагают и для расы, я написал уже текст про расу и гендерас: https://ailev.livejournal.com/1552025.html. А вот с вакцинированием и возрастом -- нельзя, тут только биология, и никаких трюков!

UPDATE: обсуждение в фейсбуке https://www.facebook.com/ailevenchuk/posts/10221536117726364
2021 год

Компьютерная революция: exploratory programming на естественном языке голосом уже в private beta

Сегодня было опубликовано видео живого демо программерской нейросетки Codex от OpenAI, https://www.youtube.com/watch?v=SGUCcjHTmGY. Вебсайт сервиса GitHub Copilot на базе этой сетки: https://copilot.github.com/ (и это может быть явно не последний сервис). Страница самого Codex -- https://openai.com/blog/openai-codex/ (и там ещё одно видео с примером. Видео важно, ибо продукты интерактивны). API Codex доступен в виде private beta с сегодняшнего дня.

Codex более-менее правильно генерирует код в 37% запросов (для сравнения: GPT-3 правильно генерирует код в 0% запросов). В видео показывают, как Codex пишет Hello World, генерирует веб-страницы и читает вебсайты, посылает письма с котировкой биткойна, генерирует по описанию простую видеоигру и даже сама сочиняет ободряющий текст для игрока в ситуации его проигрыша, а ещё выучивает JavaScript API для MS Word по его документации, и прямо с голоса вносит массовые правки в текст -- исполняя прямо в ворде программы с использованием свежевыученного API. И это только начало, первый выход в люди exploratory programming/modeling с использованием AI (там вовсе необязательно будут именно и только нейросети, и года не пройдёт, как задействуют разные другие архитектуры, нейросети будут только частью будущих решений).

А дальше читаем мои свежие тексты про компьютерную революцию и чуть более ранние текст про софт IDE и IWE и держим в уме содержание демо Codex -- что будет, если эта или подобная сетка выучит вот прямо сейчас API coda.io и тамошний язык формул, а также содержание наших курсов интеллект-стека:
-- как наши выпускники стали использовать coda.io, и мы почувствовали себя на фронтире компьютерной революции: https://ailev.livejournal.com/1577769.html.
-- что же мы такого сделали (разобрались с upper и middle онтологией, дали мета-мета-мета модель и перешли с формального языка программирования на псевдокод в части уровня формальности), и почему coda.io тут подходящий инструмент: https://ailev.livejournal.com/1578058.html.
-- про "мышление кодированием" и дописывание программ в IDE, "мышление письмом" и помощь в написании текстов в IWE (по факту демо Codex показывает и связь этих двух кейсов: кодирование в работе с текстом): https://ailev.livejournal.com/1515735.html

Мне кажется, что демо Codex делает эти три моих поста много интересней! Из этого демо нужно брать не столько текущие возможности Codex, сколько паттерны использования в живой работе и понимание уровня языка, на котором будет идти общение с помощником программиста. Это не пакетный компилятор, это нормальный REPL с естественным языком.

Дальше в соцсетях, конечно, будет много воплей про то, что программисты всегда будут нужны, что все эти нейросетки ничего не понимают в жизни и программировании (как будто программисты вот так уж всё понимают!), что они слишком много ошибаются (как будто программисты такие уж безошибочные!), что программы несовременны и неэффективны (ибо учат на допотопном коде неведомых плохих программистов, а хороший код для обучения и взять-то негде) и много чего ещё. Вот прямо комментами к этому посту много прилетит, все ж умные, все программисты от сохи (как будто я первую свою программу не написал в 1975 году, а сегодня полтора часа не участвовал в полуторачасовом айтишном совещании, как будто у меня нет студентов, с которыми мы обсуждаем вполне фронтирные на мировом уровне проекты в их фирмах! Нет, многим моим читателям ведь заранее ведь известно, что AI туп, а я так и не разобрался в ситуации!).

Ситуация же традиционна для всего нового, развивающегося по экспоненте: проходили этот общественное отрицание, гнев, торг, депрессию и принятие на цифровой фотографии, на возвращаемых ракетах, на распознавании изображений, на голосовых интерфейсах, на автомобилях с автопилотом, и программистская нежить тут не исключение. И тут олдовые программисты будут говорить, что всё будет по-прежнему, но жизнь вдруг вокруг них существенно изменится. Они обнаружат, что ведут задушевные беседы с компьютером, ибо так оказывается быстрее даже с учётом ошибок, которые неизбежно будут делать и первые, и вторые, и даже десятые версии нежити в качестве помощников программистов.

Так что компьютерная революция для меня сейчас выглядит как естественноязыковой интерфейс для exploratory programming/modeling на основе системной upper ontology и middle ontology в среде, похожей на coda.io -- и берите не текущие версии, а версии примерно двухлетней давности от текущего момента, конца 2023. Coda.io нужно примерно столько, чтобы прожевать текущую инвестицию в $0.1 млрд. (она из беты вышла только в 2019 году), инвестиция Майкрософта в OpenAI была в $1млрд., и это тоже молодая фирма. И ещё в ходе этой компьютерной революции будет конкуренция всех этих "помощников программиста", и жёсткая. При смене поколений технологий обычно непонятно, кто окажется будущем лидером. И обязательно будет надуваться инвестиционный пузырь, куда ж без этого при очередной революции!

Восторг, в какое время живём! Закупать попкорн не нужно, ибо всё происходит быстро, и некогда будет попкорн жевать, придётся бегать, и бегать много!

UPDATE: обсуждение в фейсбуке https://www.facebook.com/ailevenchuk/posts/10221531340726942, чате вычислительного мышления с https://t.me/comp_thinking/1037, чате блога с https://t.me/ailev_blog_discussion/9925
2021 год

Моделирование/программирование/онтологизирование/документирование-в-большом: лаптем или coda.io?

Мой пост про наш фронтир в компьютерной революции (https://ailev.livejournal.com/1577769.html) мало кто понял, но это нормально. Мы ж там про то, как компьютерная революция вдруг начала помогать директорам по развитию в крупных фирмах. И тут появились программисты, которые сказали, что их текущих проблем это не решает. Да, компьютерная революция в том и состоит, что решается проблема превращения обычного человека в модельера! Компьютер разворачивается лицом к людям, а не к программистам!

Эта критика неинтересна, аргументы и тезисы ровно те, которые звучали лет десять-двадцать назад, когда я активно интересовался программистской частью задачи, инструментарием моделирования -- но не очень подробно копал в саму практику моделирования, поддерживаемую инструментарием. Моделирование aka познание aka исследование тоже ведь практика, мы берём её SoTA, документируем (ага, познаём познание, размышляем о мышлении) и оформляем дальше в виде учебных курсов. А дальше нам нужен инструментарий, чтобы это всё получило компьютерную поддержку. И вот тут приходит помощь со стороны вдруг побежавшей компьютерной революции: сред моделирования и AI.

Мне нравится вот это про критический рационализм (с неявным учётом праксиологии через "It’s good to choose what to work on at any given time. We don’t have time to work on everything", https://twitter.com/reasonisfun/status/975357650752933888. Вычисления дороги, думайте над тем, о чём думать -- планируйте время своей работы, занимайтесь важным, то есть не отвечайте на любую критику, а только на интересную! И помним, что понятие "интереса" и "любопытства" вполне себе формализуется, в эволюционной эпистемологии, критическом рационализме, да и в representations learning это не просто бытовое слово. А дальше -- интересностей много, а твои ресурсы конечны, вот и планируй!):
-- Criticism helps solve your problems
-- No need to respond to all criticism
-- Criticism can highlight interesting problems
-- You’re not required to take on these problems
-- Listen to criticism only when it’s interesting.

Тем временем coda.io получила инвестиции раунда D в размере $100 млн (оценка $1.4 млрд) и говорит, что за эти деньги переработает редактор и попробует привнести в экосистему мастеров ещё и написание программ: https://coda.io/@coda/all-in-on-all-in-one-docs. “Our viewpoint is that the lines between the different document formats are artificial and that anyone can make a doc as powerful as an app,” says Shishir Mehrotra, Coda’s cofounder and CEO (https://www.forbes.com/sites/rashishrivastava/2021/07/08/all-in-one-doc-startup-coda-reaches-14-billion-valuation-in-100-million-raise-from-a-major-pension-fund/ ). Если IDE для обычных языков (я считаю фронтиром там разные варианты notebooks, которые позволяют exploratory programming), а для электронных таблиц (так это раньше называлось) среды типа coda.io склеятся, причём с учётом многозадачности и многопользовательскости (раньше называлось "операционная система"), то это будет чудесно. Это среда редактирования_представлений/вёрстки_описаний/моделирования/программирования/онтологизирования (это всё одно!), которая даёт foundational ontology. А мы туда привносим системную upper ontology и идею её нестрогости как priors для платформенного вычислителя. И показываем, как использовать для поддержки развития предприятия, то есть показываем прикладное значение. Так что критики пусть говорят расхожие соображения типа "это ненастоящий искусственный интеллект" или "это ненастоящее программирование" (вот что на такую критику отвечать?), а мы делом займёмся. Критики решают проблемы предыдущего поколения предыдущими средствами, а мы будем решать проблемы текущего поколения текущими средствами. Они (в силу другой онтологии, то есть другого выделения фигур из фона, других объектов внимания) невидимы через онтологические фильтры прошлых поколений знания. Так что сначала покажем результаты, а потом будем отвечать на вопросы "как вы это сделали". Это более продуктивно. В чём ещё фишка? В модели coda.io каждый наш выпускник становится "мейкером", который разрабатывает для предприятия "документы". С нашей стороны -- ничем не отличается от типовой работы "опытных людей" (типа вот таких работ https://coda.io/@stinger/pmm-hub-template, тысячи их, типовые шаблоны дашбордов для самых расхожих ролей в предприятии), за исключением того, что предлагается мета-модель под управлением нашей мета-мета-модели, нашей upper ontology. И это гарантирует, что дальше работа идёт с реально важным в проекте, а не первым, что пришло в голову. Что в ходе работы придётся задумываться о причинно-следственных связях, когда будут заполняться все эти документы, а не просто это формы для удобной раскладки по полочкам того, что и так ясно-понятно. У нас технология усиления интеллекта для архитекторов предприятия и управляющих изменениями, а не технология использования прикладной практики. Сотрудники же потом используют прикладную практику, готовые документы. Секретный соус в том, как мы получаем эти документы!

В coda используют довольно специфичный язык (например, существенно опираются на понятие ritual, а про "документ", который "приложение" я уж молчу. И люди, которые кодят тамошние документы -- мейкеры). Надо будет специально поразбираться с тамошней онтологией, что там за практики в их экосистеме (упор прошлой недели был на персональных практиках, а вообще они ориентированы на компании). Записал в todo себе строчку про разбирательство. Это всё из middle ontology какой-то деятельности (хотя не удивлюсь, если там и об upper ontology думают), хотя на нижнем уровне там вполне себе местнопридуманный язык программирования ("язык формул", экселевский заход). Вперёд вырываются те, кто предлагает удачную upper ontology для описания проблем предметной области. Вольфрам с вольфрам языком, coda.io с языком формул. Есть внятное описание приложений и способа жизни с этими приложениями -- всё взлетает. Нету -- и не взлетает. Jensen Huang замечал: "чтобы иметь деньги, нужно существенно сузить сферу приложения" (это когда он говорил, что абсолютно недостаточно предложить миру GPU общего назначения. Нужно предлагать что-то более специальное, типа "GPU для автомобилей" или "GPU для обработки медицинских данных", и даже не GPU, а специализированные компьютеры вместе с софтом, чтобы уж никаких сомнений в специализированности!).

Скажем, система, которая копировала бы coda в части общего подхода (хороший редактор для встречающихся в корпоративной практике структурированных и неструктурированных данных и API для липкости к корпоративному айти-пейзажу), а языком бы имела Julia (это ж фронтир языка) могла бы иметь шанс на успех для data scientists. Но Julia это не язык для low code. Так что там ещё нужно что-то типа майкрософтовского голосового интерфейса к автоматизации, порождение кода из словесных запросов на естественном языке. И как у Вольфрама -- готовые обширные библиотеки, дающие не самые оптимальные, но работающие "из коробки" и согласованные друг с другом по интерфейсам типовые решения. Тут native Julia была бы более чем хороша. Лет двадцать назад меня грели идеи примерно такого сорта, я бы непременно затеял стартап на эту тему. Но не сегодня.

Сегодня я просто продолжу заниматься тем, чем и занимаюсь: буду делать людей умнее, но на другом уровне интеллект-стека. Доработаю SoTA upper ontology в классическом понимании этой upper ontology (ага, начиная с "возможных миров"), как-то покажу, как её двигать в middle ontology (деятельностные кругозоры, тоже вполне себе классическое понимание), доведу до изложения в виде учебных курсов и покажу, как использовать с SoTA версиями тех айтишных систем, которые уже вышли в production, а хоть и coda.io. Notion.so тут тоже сойдёт, и даже флипчарт с фломастером сойдёт, хотя они будут хуже coda.io. Наш продукт (я ж не один работаю!) -- это мастерство задействовать в качестве персонального и/или корпоративного экзокортекса всё что угодно, и при этом рационально понимать, что из этого "что угодно" лучше, а что хуже, и для каких именно целей.

Смею заверить, ответы на вопросы "а чем хуже notion или airtable или Google table" есть, это ж первый вопрос, который людям в голову приходит! Если такой вопрос у вас есть, то вы ещё не в теме. Приходите, когда этого вопроса у вас уже не будет. Но и не удивляйтесь, когда выяснится, что coda.io -- это только одно из возможных решений. Если вам нужно копать, то можно и лопатой, и экскаватором, и иногда даже ложкой. Главное, чтобы не голыми руками, и не в одиночку. Вот мы так же относимся к моделированию/программированию/онтологизированию/документированию-в-большом. А лаптем это делать или coda.io -- это уже неважно. Хотя постойте...

Ссылок опять не даю. У меня десяток лет назад было много постов про всё это программирование-в-большом. А пару лет назад и про мышление письмом/моделированием (и, конечно, программированием). И там более чем достаточно всё расписано. Сейчас просто все отдельные части этих рассказов, наконец, собраны вместе и работают даже не у нас, а у наших выпускников. Ровно как обсуждал Алан Кей: без излишней сложности, разворачивание оказывается дешёвым и быстрым, а применение развёрнутого (управление вниманием в компании) -- эффективным. Мы рекомендуем подобные продукты для поддержки деятельности директоров по развитию. Особенно хорошо получается, когда директора по развитию (они могут называться и CIO, дело ж не в названии должности) сами моделируют/программируют, как начальники сейчас сами пишут в чат, а не диктуют секретарю-машинистке.
2021 год

Мы на фронтире компьютерной революции, лето 2021

Свежий пост про 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
2021 год

lytdybr

ОдО переписано на 39%, переписывал сегодня кусочек про неработу трёхдневных курсов. Радикальных изменений нет, просто уточнения формулировок и чуть-чуть примеров (хотя примеры тоже получаются довольно абстрактны, я ж больше о трансдисциплинах говорю и об обучении, цепочка длинная получается -- примеры по-хорошему нужно дотягивать до момента, когда вся эта цепочка сработала или не сработала в каком-то проекте. Но оставлю это на третье переписывание, текст и без этого подраспух).

Прочёл сегодня на Архипелаге очередной двухчасовый обзор системного мышления, видео -- https://youtu.be/vwotFnYBIS0, слайды вот: https://yadi.sk/i/UPkHGCknBbL-gw. Там, конечно, на этом Архипелаге большой проходной двор: люди приходят и уходят во время рассказа, но десяток человек из пятидесяти заранее записавшихся таки прослушал всё от начала до конца. Конечно, потом видео просмотрят несколько сотен человек, для этого и стараюсь. Всё становится асинхронным: все эти доклады, лаборатории, мастерклассы и прочая активность превращается просто в сеанс видеозаписи. Люди смотрят не на то, как я рассказываю вот прямо сейчас, но "листают" видео моего рассказа на полуторной скорости когда-нибудь потом, когда у них есть подходящее для этого просмотра время. Этот просмотр-листание обычно на бегу, где-нибудь в машине в поездке, когда на экран с диаграммами, обложками книг и аутлайном текста и не посмотришь, и внимание наполовину направлено на дорогу и вождение, а наполовину -- на звучащий рассказ. Но это уже хорошо, прослушанная одна минута уже лучше, чем ноль минут! Хотя представление о системном мышлении от прослушанного пунктиром рассказа может быть очень превратным!

Фейсбук забанил мой комментарий про недостаточную инженерность математики, пост с этим скриншотом получил за сутки 67 лайков и 5 шеров, https://www.facebook.com/ailevenchuk/posts/10221467114361323. Это давний комментарий забанен был только сейчас, причины неизвестны -- хотя я там честно признаюсь, что текст мой мракобесный. Я и второй забаненный комментарий в фейсбуке нашёл, но там не про математику, а про радужный столб, и вот радуга мы ж знаем, её лучше не обсуждать!

Что касается содержания, так онтологический статус математики я представляю себе много лучше. Вот есть computer science, как естественная наука, и Дэвид Дойч примерно описывал взаимные отношения математики и computer science. Тут нужно сказать, что споры по поводу понятия вычислений с их Theory A и Theory B до сих пор ведутся, и квантовый компьютинг (и, думаю, оптический компьютинг тоже сюда добавит) не даёт этим спорам заглохнуть. Вот там такие работы как "Finite of Sense and Infinite of Thought: A History of Computation, Logic and Algebra", a history of the development of computation, logic and algebra from classical times to the twentieth century, told through primary sources -- https://pron.github.io/computation-logic-algebra с рассуждениями про различие вычислений как логического вывода (работа с абстракциями) и вычислений как моделирования (семантика языков программирования) в https://pron.github.io/posts/what-we-talk-about-when-we-talk-about-computation. Вот мне в ОдО нужно будет про информатику и системную информатику писать, а полного понимания ситуации с возможными курсами на эту тему у меня нет -- и, похоже, ни у кого нет. Понятно, что там должна быть пара курсов (теория/объяснения и деятельностный кругозор системной информатики как системной инженерии вычислителей с описанием SoTA практик), но вот с содержанием ещё нужно будет разбираться и разбираться.

Не выдержал и откомментировал у Розова про равномерность (хотя и экспоненциальную равномерность) развития: ну нету какого-то отдельного всплеска или торможения у прогресса в 80е годы прошлого века, хотя Розов и особо выделяет этот период (Пинкер хорош тем, что на подобранных им графиках эту непрерывность наблюдать удобно. Одно дело субъективное перечисление "важных событий", другое дело когда смотришь на данные -- и понимаешь, что какие-то события ведь происходят всегда!). Вот тут эти комменты, начиная с: https://alex-rozoff.livejournal.com/440776.html?thread=121510856#t121510856.