Category: лытдыбр

2019

lytdybr

Принимал сегодня экзамен по системному мышлению у техпредов МФТИ, очники. Фейспалм. Мой совет им -- RTFM, я его четырежды переписывал как раз по итогам предыдущих сдач, с 2012 года ежегодно, опыт ведь накоплен немаленький. На каждой консультации говорил, что нужно читать учебник, а не смотреть видео. Нет, смотрели только видео, и не до конца, и невнимательно -- и воспроизвели все типичные ошибки тех, кто смотрел только видео, и не до конца, и невнимательно. Те, кто читал учебник, такие ошибки уже не делают. Основная печаль, конечно, по поводу онтологики: https://ailev.livejournal.com/1465753.html. Аналитики на аналитике и аналитиками погоняют: то, что все эти описания и отчёты описывают какие-то системы (в конечном итоге описывают что-то в физическом мире) -- эта мысль не понимается. Отношения часть-целое заменяют словом "объединение", используют в смысле "почта России объединяет всех жителей России". Вопрос "являются ли жители России физической частью почты России?" ставит в тупик -- разницу отношений, обозначаемых термином "объединение" понять не можем: слово-то одно! Функциональные описания не поняты от слова "совсем", пять слов "модуль" под заголовком "функциональная диаграмма" никого не смущают -- считают, что преподаватель явно ведь придирается! Впервые вижу такое безобразное отношение к предмету (время на него студентами не тратилось вообще, все эссе писались за пару часов до экзамена, учебник не читался, видео "листалось"). Результат: нулевое понимание, что и фиксирует экзамен. При этом группа онлайн-магистратуры (там ребята чуток постарше) демонстрирует ровно обратное поведение: активное посещение консультаций, много вопросов, нормальная связь учебного материала с жизнью. Молодые же содержания предмета не знают, но пытаются качать административные права. Ну, они этих административных прав преподов получат по самое не балуйся. А всего-то нужно было вовремя читать учебник, к первым консультациям, которые шли пару месяцев назад. Времени ведь было навалом, преподы были свободны. Нет, синдром студента таки победил. Именно эту группу. Дружно, всем коллективом. Эх.

Обсуждаем очередное переструктурирование курсов онтологики -- обсуждается объединение всех микрокурсов в один большой курс, чтобы гарантировать хоть какую-то целостность материала в головах курсантов. Вот эта программа (это уже третья большая переделка: онтологика, потом онтологика 2.0, потом разбиение на 5 отдельных курсов -- и вот новый вариант содержания): https://thpectrum.livejournal.com/13568.html. Моя критика там простая: указанное содержание полностью ОК, но указанное время -- оно слишком мало, обучить надёжно за это время не удастся. Машинку типов за ползанятия в головы не вставишь, байесовщину за один вечер не поймёшь. Нужны какие-то реалистичные оценки времени обучения (даже с учётом интенсивной домашней работы). Но программой можно гордиться. Факультеты философии, методологии науки и т.п. в крупных университетах пусть завидуют.

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

В группе шестнадцатого потока "Системный менеджмент и стратегирование 2019" мы нагнали полдня, и теперь идём примерно по графику предыдущей группы -- то есть всё успеем вовремя. Но если прошлая группа застревала на управлении конфигурацией, то эта группа застряла на архитектуре: функциональные и конструктивные описания (да ещё и в различении практик и работ в том числе). Это означает, что материал архитектуры предприятия можно почти и не рассказывать: там же ровно вот этот материал ключевой! В группе очень интересные проблемы вскрываются: даже найден пример "скрипки Энгельбарта" в рабочей жизни курсантов (https://ailev.livejournal.com/1158826.html). Один из курсантов при попытке применить материал курса обнаружил неучтённые 60млн. руб -- так что курс для него уже окупился. Брали бы студенты-очники пример с этой группы в части отношения к учёбе! Хотя один студент таки написал мне в личке буквально перед экзаменом, что "впервые за 6 месяцев работы и размышлений над проектом взглянул на него совершенно иначе (это все равно никак не влияет на корректность эссе, но лично меня очень радует), задумался, для кого это все делается и как это влияет конкретно на меня. В общем - спасибо!". Ну, это дословно совпадает с тем, что я говорил на установочной лекции: именно при составлении эссе вы впервые вынуждены будете подумать о вашем проекте в целом -- и вас там будут ждать разные (приятные и неприятные) открытия.

На курсе социального мультиданса начали приглашать преподавателей и опытных танцоров поглядеть на результаты. Их (внешнее! не наше!) мнение: обучение ведению-следованию быстрее примерно вшестеро, чем в среднем при текущих методов преподвания. И это сразу для многих танцев, а не для одного! То есть выигрыш во времени по факту ещё больше. Так что ещё один крутой проект одолел успешный успех: методика работает! Почитать о происходящем в группе (резюме каждого занятия, методические материалы, а также публичную часть отзывов) можно тут: https://vk.com/buffdance (и там уже 311 подписчиков, счёт интересующихся методикой пошёл на сотни). Лаборатория телесного мышления начала еженедельно выкладывать видео своих лабораторий (чат в телеграме -- https://t.me/labolatoryTM, там более полутора сотен человек), и теперь довольно много убедительных демонстраций телесного фитнеса и разъяснений его принципов доступно не только москвичам и питерцам.

Следующий открытый курс у меня -- "Машинный интеллект 2019", 7 декабря 2019 (https://system-school.ru/machine). Материал на слайдах опять прокис, буквально за месяц -- два прорыва в неделю продолжаются. И я переделываю там ещё и теоретическую часть. Ибо 19 ноября вышла статья François Chollet по тому, что такое интеллект и как его замерить (https://arxiv.org/abs/1911.01547) -- и я учитываю ещё и этот материал. Ну, добавляю всякие новости прошлого месяца, а этих новостей много -- если я не пишу обзоров происходящего у себя в блоге, это совсем не значит, что ничего не происходит. Происходит, и ещё как происходит! Чего стоит только Mastering Atari, Go, Chess and Shogi by Planning with a Learned Model -- https://arxiv.org/abs/1911.08265. Умение алгоритма выигрывать самые разные игры, не зная их правил, и делая при этом меньше вычислений при обучении, чем алгоритмы, которые учатся играть в игры, зная правила. Фишка в том, что один и тот же алгоритм сверхчеловечески выигрывает и в видеоигры типа тех, что играются на Atari, и игры "переборного планирования" типа Го, шахматы и шоги, при этом не зная правил ни игр на Атари, а их 57 разных, ни правил Го, шахмат, шоги. Это очень, очень круто! По сути, речь идёт не о том, что алгоритм запрограммировали не на победу в какой-то игре (ограниченная компетенция), а об общей возможности побеждать в каких-то играх, где правила неизвестны, но есть симулятор, дающий ответы на ходы машины -- это возможность научиться выполнять какой-то класс задач. Интеллект -- это в меньшей мере про умение что-то делать, а больше про умение научиться что-то делать -- когда выясняется, что текущих умений для выполнения дела недостаточно.

И в связи со всем этим я дополнительно пересматриваю "Образование для образованных" -- наша Школа ведь как раз учит трансдициплинам, которые предназначены для разборок с другими дисциплинами. Мы учим тем практикам, которые позволяют быстрее разбираться с другими практиками. По сути дела, мы учим тому, как стать более интеллектуальными людьми, более разумными, быстрее распознавать ситуации, когда нам нужно чему-то научиться, а потом быстрее этому учиться. Так что я потихоньку разбираюсь со всеми этими теориями интеллекта (g-VPR, CHC, Gf-Gc и т.д.), а дальше мы будем связывать их с разными теориями творчества (некоторое время назад я делал обзоры на эту тему, например творчество в системном мышлении -- https://ailev.livejournal.com/1425331.html, open-endedness про эволюционное "творчество" https://ailev.livejournal.com/1463013.html и разные теории творчества из искусственного интеллекта https://ailev.livejournal.com/1251987.html, и ещё куча материалов, поминаемых в конце текста "За пределами менеджмента и инженерии" https://ailev.livejournal.com/1411106.html, где я пишу о связи творчества и сжатия информации -- про правильную репрезентацию/абстрагирование мира как основу творчества, и поэтому важности обучения эффективным абстракциям. Интеллект и творчество в машинах, людях и симбиозах машин и людей -- этим мы и занимаемся.

Дома появился новый гаджет -- МФУ HP DeskJet Ink Advantage 5075 M2U86C, а старые принтер и сканер уволены по моральной старости. Из интересных фич -- двусторонняя печать при весьма небольших габаритах. Стоит этот гаджет на кухне, пользуются им все -- он цепляется к домашнему WiFi и доступен со всех компьютеров и телефонов. Больше гаджетов богу гаджетов! А что я им делаю больше всего? Правильно: "распечатать, подписать, отослать подписанный скан". Морально не устаревающая процедура, ещё со времён факсов. Факс даже проще было передавать, чем сканировать и пересылать результат по почте -- в разы меньше нажатий кнопок.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216874837917282
2019

Об цифровую трансформацию: то же оргразвитие, и даже не в профиль

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

Цифровая трансформация -- "цифровая" означает, что будет много компьютеров. Как будто их не было и в автоматизации! Автоматизация -- вроде как что-то делал человек, а потом это же стал делать компьютер. Но нет, если что-то стал делать компьютер, то он это будет делать по-другому, и человек тоже займётся чем-то другим: организация от использования компьютеров не столько "автоматизируется", сколько "трансформируется". Ага, с использованием компьютеров. По сути дела, речь идёт об организационном развитии

Можно было бы поддаться веянию времени и начинать говорить о цифровой трансформации, это ж синоним (цифровой -- компьютеризированный по самые брови, трансформация -- это как раз оргразвитие), но этот термин как придёт, так и уйдёт. Скоро, скоро уже заговорят о какой-нибудь "искусственноинтеллектуальной трансформации" или как это будет называться (когда выяснится, что подойдёт не просто работа с данными, а только работа с данными при участии машинного интеллекта), заменят компьютеры на квантовые -- это будет "квантовый оргскачок" и так далее. Вон, несколько дней назад Гартнер выдал новое слово "hyperautomation", гиперавтоматизация. Что, выучиваем и его? Больше buzzwords богу buzzwords?

Мы помним, что почта вдруг стала электронной, а потом просто почтой (а потом переписка ушла вообще мессенджеры и какие-нибудь Slack или MS Teams). Бухгалтерия тоже становилась механизированной (с Феликсами и табуляторами на перфокартах), а потом компьютеризированной, а потом осталась бухгалтерией.

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

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

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

Подробней об этом я писал в:
-- системная осознанность, https://ailev.livejournal.com/1487672.html
-- киборгизация людей и организаций: поднимаем осознанность, то есть рулим вниманием, https://ailev.livejournal.com/1488271.html

И мы всё это используем в нашем проекте развития -- использование информационных технологий в реализации стратегии Школы:
-- EdTech для blended learning -- те же PLM/ALM + CAD/CAM/IDE, только в образовательный профиль, https://ailev.livejournal.com/1473691.html
-- чего мне не хватает в MS Teams -- https://ailev.livejournal.com/1490524.html
-- стратегирование Школы системного менеджмента -- https://ailev.livejournal.com/1493744.html
-- видео семинара по созданию AIsystant и blended learning services, https://ailev.livejournal.com/1494270.html
-- чеклисты в blended learning services: не прощёлкать важное, но и не забюрократизироваться, https://ailev.livejournal.com/1497117.html
-- множество заметок в lytdybr (например, https://ailev.livejournal.com/1496250.html -- там я говорил про RPA как ведущий тренд)

Дальше нужно понимать, чем же именно проекты развития с компьютерами отличаются от "просто проектов развития". По большому счёту, ничем. Но в этих проектах развития заимствуется огромное число находок из управления жизненным циклом и управления работами из software engineering. В частности, в управлении жизненным циклом из существенных новаций можно заметить DevOps (плавно переходящее в NoOps, https://ailev.livejournal.com/1367897.html) и свеженький его извод SRE (site reliability engineering, включая обширную дискуссию его похожести и отличий от DevOps -- главным образом то, что в NoOps куда-то делись Dev, а в SRE они в полной мере присутствуют).

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

В НИУ ВШЭ мы читаем также курсы в магистратуре "Цифровая трансформация образования" -- https://www.hse.ru/ma/dt/. Там, конечно, всё завязано на госбюджет, поэтому "цифровая трансформация". Мы же сказали бы просто: это школа менеджеров развития образования. Если есть практика организационного развития, то есть и деятельностная роль -- управляющие развитием, менеджеры развития.

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

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216830525489499
2019

lytdybr

Слетал на сутки в Сочи, позанимался там системным мышлением с инженерами, моря не видел. Узнал, что корпоративная стратегия, над которой работали четыре года назад, начала реализовываться в каких-то частях. В момент её создания нам казалось, что шансов нет. Прошло четыре года, и дело пошло. Это не первый консалтинговый мой проект, в котором рекомендации начинают выполняться сильно погодя. Я подозреваю, что в обучении всё то же самое: учатся сейчас, а использовать результаты обучения будут через несколько лет, когда забудут всё содержание, но зато прочувствуют, что без этого забытого содержания никак нельзя. Собственно, в Сочи летал примерно по тому же принципу "позднего прочувствования": за четыре года альтернативных системному мышлению методов договаривания инженеров и менеджеров клиентом найдено не было, так что я съездил презентовать учебник. Но и то правда, что четыре года назад был только второй вариант текста учебника, а сейчас уже четвёртый.

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

Вот наш первый класс:


Вот одиннадцатый:


Дальше принято с довольным видом писать: "я сделяль". Вот, пишу.
2019

lytdybr

Группа "Системного менеджмента и стратегирования" (шестнадцатый поток! третья версия курса!) опять отстала на полдня от графика. Прошлый поток более подробно проходил управление жизненным циклом и управление конфигурацией. А вот эта группа вдруг вернулась к материалу про функциональные объекты, функции, порты и соединения против конструктивных объектов, сервисов, интерфейсов. При этом в материале управления жизненным циклом по этой же линии различали практики и работы. Баек (то бишь "примеров из жизни") было рассказано немерено. Половина группы -- строители. Но есть и парочка "маркетплейсов", и диалоговые AI-боты. Как всегда: одно мышление, помогающее во всех проектах. А ещё час был потрачен на вопрос об управлении вниманием с использованием технических средств -- на примере меня, любимого (основной тезис был: "это не у меня память хорошая, а у Гугля". Ну, и дальше по мелочи -- полторы тысячи заметок в Evernote, почти шесть тысяч записей в "Лабораторном журнале", обсуждение на почти тридцать тысяч моих комментов в ЖЖ и несчитанное количество в фейсбуке и других сетях, и прочие средства помощи коллективному мышлению с моим участиемсо стороны компьютеров и интернета).

Завтра вечером вылетаю в Сочи на корпоративную конференцию, буду там всю среду заниматься системным мышлением в части обеспечения смычки между инженерами и менеджерами (увы, в той тусовке с предпринимателями будет туговато). Участники конференции даже учебник получат бумажный, лишь бы учились. Всё это "государственный бизнес", то есть не бизнес, и поэтому весьма искажённая инженерия (не очень системная). Но учить буду: сегодня тамошние инженеры и менеджеры работают в госкорпорации, но мы не знаем, где они будут работать завтра -- поэтому осмысленно их учить (но не консультировать по их текущим проектам. Именно учить, готовить к реальной инженерии и реальному менеджменту, а не искажённому дармовыми для них деньгами налогоплательщиков). В мировой системной инженерии (и заодно менеджменте), которые быстро-быстро отплывают от государственного финансирования, сейчас идёт выход на принципиально иной уровень сложности: четвёртый запуск одной и той же ракеты Falcon 9 (и второй запуск сохранённого обтекателя), которая вывела на орбиту 60 первых (то есть не экспериментальных, а рабочих) спутников StarLink -- https://www.space.com/spacex-starlink-launch-fourth-rocket-landing-success.html. Эта ракета планируется быть запущенной в космос и в пятый раз -- об этом говорится явно. В середине 2020 сеть StarLink уже планирует начать работу -- и интернет опять существенно поменяется. Вот это -- и бизнес, и инженерия. Про бизнес SpaceX, кстати, читайте вот тут: https://smoliarm.livejournal.com/419187.html (текущее снижение цен на запуск малых спутников силами SpaceX втрое-вчетверо).

Провели методологический семинар по схематизации и рендерингу (обсуждали https://ailev.livejournal.com/1494762.html). Написал длинный протокол в преподский чат. Содержание трёх курсов (онтологики, схематизации, коммуникации) будет в ближайшее время существенно пополнено и доработано. Длительность курсов увеличится. Очень хочется, чтобы состояние курсантов "знакомы с идеями, очень интересно" перешло в состояние "имеем компетенции, используем "на автомате"". Пока же, увы, этим похвастаться не можем. Для интересующихся темой агентности и обучения мышлению рекомендую поглядеть текст про обучение мышлению машинного интеллекта (и я считаю, что это же применимо для обучения мышлению и человеческого интеллекта тоже. Поглядите, там все слова знакомые): https://medium.com/intuitionmachine/an-advanced-capability-maturity-level-for-artificial-general-intelligence-b300dafaca3f. Просвещение переводит людей со ступеньки неосознанной некомпетентности к осознанной некомпетентности. А дальше — образование.

Провели методологический семинар по Айсистенту и blended learning services. Неожиданно тема SysMoLan пересеклась с тематикой RPA (и да, там новости по линии Microsoft -- https://venturebeat.com/2019/11/08/microsoft-has-entered-the-rpa-market-what-does-that-mean/). Текущий RPA состоит из набора коннекторов к софту, набора коннекторов к человеку (все эти распознавания речи), плюс BPM-движка (можно думать, насколько там близко к case management -- они ж себя процессниками считают, и языки там типа CMMN есть, хотя пока выглядит как "голимый недоBPMN"). На чём пишут архитектуру RPA? На диких скриптовых языках довольно низкого уровня, "архитектуры нет, есть коды -- они же документация". Дальше вопрос "адаптивности" как в кейс-менеджменте: если шаблоны пишут программисты, то "просто кейс-менеджмент" (так что RPA сегодня это "просто RPA"). Но если шаблоны пишут непрограммисты, то это будет adaptive RPA. Очередной виток процессного управления. Дальше вопрос: кто пишет на SysMoLan. Если SysMoLan это язык представления знаний (скажем, Common Logic или что-то типа CYC и так далее по линии логических движков), то редкие люди, их в природе единицы. Если SQL (первое же, что предлагают обычно), то герои-админы. Если DSL на Julia, то можно думать об инженерах (но именно что думать). В любом случае, речь в Айсистенте идёт о том, чтобы скриптами (конфигурация -- это код) держать федерирование нескольких разных тяжёлых систем типа той же Teams, корпоративного вебсайта, биллинга и т.д.. В общем, после этой встречи есть о чём подумать. Опять же -- длинный протокол, хотя и не в преподавательской, а в спецчате.

Заодно отладили интерфейс решения задач по системному мышлению. Там решаются программерские проблемы, и я очень надеюсь, что в конце этой недели первая группа из 15 студентов ВШЭ начнёт идти по курсу из учебника-2019 и кейсы-2019 с проверкой. Напомню, постановка задачи была вот тут (и задачи после этого хочется называть кейсами): https://ailev.livejournal.com/1482241.html

Один из побочных выходов посиделки по Айсистенту -- уточнение пары кейсов на один уровень:
Курс
-- решить про курс
-- найти препода
-- подготовить материалы
-- заслушать на семинаре
-- дать анонс (видео)
-- сделать landing page
-- перейти к ЖЦ первого потока
-- менять материалы курса
-- уволить курс

Поток
-- согласовать с преподом курс и время
-- дать объяву на сайт + вставить в расписание
-- начать сбор заявок ("объявить набор")
-- в день X принять решение о старте потока (ибо может быть недобор, или может быть перебор, тогда запустить набор на новый поток, а этот продолжить)
-- оформить договора и оплаты
-- прогнать через онлайн курс (учебник+задачник)
-- дать доступ к материалам курса (библиотека+слайды. Слайды могут быть к каждому дню "оперативно", а не сразу)
-- завести списк курсантов потока
-- завести для курсантов чат потока
-- завести репо для материалов потока
-- зарезервировать аудиторию (возможны пересечения с другими курсами)
-- вести занятия потока (координация через чат): использовать аудиторию и дистант (сейчас ZOOM)
-- снимать и публиковать видео только для потока
-- проверять домашние задания в репо
-- провести защиту
-- выписать сертификаты
-- занести курсантов потока в чат выпускников (закрытая коммуникация)
-- занести курсантов потока в список выпускников (у них будут скидки)
-- занести курсантов потока в комьюнити выпускников (фейсбук, открытая коммуникация)
Опубликовали первое видео наших курсантов социального мультиданса: https://vk.com/wall-179019873_373. В группе много выпускников курсов ШСМ, а на видео есть два профи -- сможете их отличить от начинашек в танцах? Методика работает, ускорение обучения социальным танцам получается в разы по сравнению с традиционным способом, я очень доволен. Чему мы учили целый месяц эту группу, сформулировано вот тут: https://vk.com/wall-179019873_372. А ещё получили развёрнутую правильную рецензию от приезжавшей к нам на пару дней Елены Унру из Питера (и там фотография меня, изображающего непослушную партнёршу): https://vk.com/wall-170497991_610. Правильность рецензии в том, что про социальные танцы нужно именно так и писать: про ощущения в паре, а не про внешние формы. Из забавного: использовал свежую разработку MIT по равновесию двуногих роботов для разговора о равновесии в социальных танцах -- https://vk.com/wall-179019873_374. А вот и я попал на видео танцующим -- на вечеринке Ностальжи Кизомба в эту субботу: https://vk.com/video40271596_456239303. И ещё один мой текст: про удовольствие в социальных танцах -- https://vk.com/wall-179019873_367.

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

Блюдо недели -- тыквенная запеканка из Пан Запекан (при этом тыква на вкус там не обнаруживается ни мной, ни другими людьми -- проверено. Но очень вкусно). Я пришёл туда целевым визитом (у меня их точка на Октябрьской в самокатной доступности, прицелился и назначил там встречу-обед), не рассчитал вес-объём, и взял 0.7кг разных запеканок. Едва осилил, под 0.4л латте. Правильное место, я такие люблю: показываешь пищу пальцем и немедленно её получаешь, а не тыкаешь в фотографию из меню и потом ждёшь сюрпризов.
2019

lytdybr

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

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

Я таки победил multiraw tabs в FireFox 70, по вот этой методе: https://github.com/Izheil/Quantum-Nox-Firefox-Dark-Full-Theme/tree/master/Multirow%20and%20other%20functions/Multirow%20tabs. Жизнь улучшилась несказанно.

Оказывается, я до сих пор умею стоять в первой позиции. Это мы провели лабораторию по системному фитнесу в балете, сняли её на видео и вот мои заметки и видео: https://vk.com/wall2449939_2475. Я там предложил по типу социального мультиданса выполнить моделирование для всех этих балетов, джаз-модернов, контепорари и всего из этой серии. И учить сразу всему, а не одному "чистому стилю". Мультибалет, почему бы и нет. А ещё получили внешнюю рецензию того, что происходит у нас в классе социального мультиданса, и очень положительную: https://vk.com/wall-179019873_366.

Бабушкины оладьи и баклажаны с моцареллой в братьях караваевых -- блюда недели. Сегодня баклажан с моцареллой не было, а оладьи конкурировали с налистниками. Победила дружба, пришлось есть и оладьи, и блинчики. Чабрецовый чай и какао тоже попробовали конкурировать -- но и у них победила дружба.
2019

lytdybr

Перевёрстываю слайды по машинному интеллекту 2019, ибо лекцию читаю уже в это воскресенье. За пару недель произошло много чего интересного: двинулся leaderboard в SuperGLUE (человек: 89.8, T5 от Гугля: 88.9), Waymo в аризонском Фениксе стало возить без страхового водителя несколько сот человек (подписавших соглашение о неразглашении), автомобили могут видеть за углом при помощи анализа едва заметно меняющихся теней (ShadowCam: when sensing and stopping for an approaching vehicle, the car-based system beats traditional LiDAR — which can only detect visible objects — by more than half a second), а ещё добавил про superhuman машинные переводы на WMT в этом году. Средства самоцензуры брендов в социальных сетях (чтобы случайно не нарушали законодательство в своих высказываниях), выявление плохих пицц и плохих работников в Domino (и чтобы откреститься от "технологии слежки" компания говорит, что это "инструмент для обучения" -- ткнули в тебя пальцем, сказали, что ты плохой работник, и пиццы твои плохие, так это обратная связь, тебя просто учат!). А ещё несколько команд выдали AI, сдавшие наш ЕГЭ и даже прошли порог поступления в вузы. Quantum supremacy в таком состоянии (после заявлений Гугля и отповеди IBM), что игнорировать её дальше уже нельзя. Опыт показал, что такую обзорную лекцию по машинному интеллекту можно прочесть за день (это ведь будет уже второе прочтение, первое было тут: https://ailev.livejournal.com/1492738.html). Но машинный интеллект используется практически везде, где используется человеческий интеллект, и поэтому однодневную лекцию тут читать примерно так же, как читать однодневную лекцию про человеческий биологический интеллект: "люди крайне умны! Сейчас я вам по-быстрому расскажу, что это такое, и где это применяется". И в этой шутке есть только небольшая доля шутки.

В старом XPS 13 2015 батарейка таки вспухла (я ужаснулся, когда её увидел вытащенной. Вовремя я спохватился! Ещё б чуток, и её бы просто разорвало) -- заменил вчера её на новую, и заметно покривившийся старый ноутбук тут же стал ровным. Без устали колочу в админский бубен над новым ноутбуком. Например, полный интернет записей о том, как убрать приветственный и блокировочный экран в Windows 10, но если пароля нет, то эти инструкции не работают. Убрать блокировочный экран без входного пароля в Windows 10 можно вот по этой тайной (нашёл только на одном форуме) инструкции: в "Выполнить" введите "gpedit.msc", а затем нажмите Enter. В появившемся редакторе локальной групповой политики в левой панели, перейти к Конфигурация пользователя> Административные шаблоны> Система> Варианты действий после нажатия CTRL+ALT+DEL. Справа, найдите параметр "Запретить блокировку компьютера" и дважды щелкните по нему. В окне свойств, которое откроется, выберите опцию Включено и нажмите кнопку ОК. Теперь вы можете выйти из редактора локальной групповой политики. Изменения вступают сразу без перезагрузки. можете проверить сразу нажав на (Windows + L) картинка с кнопкой "войти" не появится. Если в любое время вы хотите включить блокировку, выполните ту же процедуру и установите эту опцию обратно как "отключен" или "не настроен".

Пока изо всех проблем с новым ноутом я хоть как-то удовлетворительно я не справился только с multirow tabs в FireFox 70. Это оказалось отдельным приключением (при этом на старом компьютере у меня они есть!).

Сходил на семинар Ronie Saleh по музыкальности в кизомбе, написал об этом вот тут: https://vk.com/wall2449939_2449. Я уже третий год попадаю на его семинар, предыдущие тексты можно найти по ссылкам в первом абзаце тут: https://ailev.livejournal.com/1452638.html. А вообще про танцы разную методологию я продолжаю писать в https://vk.com/buffdance. Те, кто танцует со мной кизомбу уже признают, что у меня в танце не кизомба - но что? Зук, хастл, бачата, хотя я ничего этого не танцую, и говорят всё такое разное про одни и те же движения. А это я просто танцую общую основу для всех этих танцев: шаги да повороты в разных направлениях. И каждый в них видит своё родное-знакомое и называет своими такими разными именами. А вообще-то я как-то снизил в октябре время активного танцевания, с октября какой-то невиданный поток вечерних рабочих мероприятий. И до вечеринок добираешься дай бог к 22 часам, если вообще добираешься.

Дом завален звёздными картами в количестве, ибо астрономия сейчас проходится в 11 классе. Вовремя, вовремя. Грузовой Starship хочет прилуниться ещё до 2022 года, после чего почти сразу летать туда с космонавтами на борту, а спутников связи Starship будет выводить по 400 штук за один полёт (а всего их планируется 30тыс. штук на орбите, один из самых амбициозных инженерных проектов сегодняшнего дня) -- https://www.cnbc.com/2019/10/27/spacex-president-we-will-land-starship-on-moon-before-2022.html. Вот сейчас это похоже на настоящее развитие, ибо для денег и пользы людям, а не просто для военных целей или для славы.
2019

lytdybr

Через Ridero на сегодня продано 4306 книжки по системному мышлению, и 768 по визуальному мышлению (что меня вообще восхищает -- не ожидал ни разу такого интереса). То есть всего 5064 книжки, "психологический барьер" незаметно пройден.

Набор на курс Кирилла Гайдамаки "Как учиться эффективно?" открыт, он пройдёт 2 ноября 2019, восхититесь программой (курс основан не на популярных/журналистских книжках об обучении, а на нормальных научных работах): https://system-school.ru/study

Сегодня провели методологическое совещание, подтвердили, что Школа должна заниматься исследованиями, образованием (то бишь обучением каким-то прикладным вещам) и просвещением (то бишь нести обществу весть о текущем мировоззренческом фронтире, вытаскивать массы из дикарства). Конечно, там много словоблудия по поводу разницы между образованием и просвещением, но мы пока плохо выполняем дело "Просвещения-2020" (https://ailev.livejournal.com/1430302.html). Образовывать образовываем, но очень узкий круг людей. Свет у нас есть, но мы не очень несём его в массы. А надо бы.

Активно обсуждаем развитие курса "Схематизация на салфетке и в уме" (курс https://system-school.ru/modelling, четырёхминутная презентация курса https://youtu.be/1BO43AH2asI). Речь идёт о гарантированности обучения как собственно схематизации, так и входящего в курс, но не выпячиваемого сейчас рендеринга. Сам курс должен давать компетенцию движения по спектру формальности мышления. Но если говорить попсово, то курс учит осмысленно и целенаправленно читать, писать, говорить. Обсуждение курса риторики подняло ещё целый ряд вопросов (см. мои заметки https://ailev.livejournal.com/1491835.html и обсуждение в первом абзаце https://ailev.livejournal.com/1492409.html схематизации и рендеринга на разных теориях концептов). Так что решили учинить методологический открытый семинар, где обсудить ситуацию и спланировать набор курсов: что там базовое, что прикладное, какие могут быть преподаватели, какой опыт текущего обучения схематизации и рендерингу. Приходите 30 октября 2019, 19 часов -- https://www.facebook.com/events/923926258007196/

IT-сервисы Школы получили общее имя AIsystant (тут и AI, и SYStems, и assistant). Это все курсы школы, администрирование потоков и т.д.. А платформа для поддержки этих сервисов получила наименование blended learning services. Мы собираемся обсудить что там должно быть и кто что думает по этому поводу на открытом семинаре 25 октября 2019 в 18 часов. Приходите, а чуть больше информации и разные ссылки на эту тему я написал вот тут: https://www.facebook.com/groups/blended.learning.russia/permalink/2441204019455466/ (это пост в сообществе blended learning в фейсбуке). Конечно, работа по созданию Айсистента связана с проектированием и документированием архитектуры предприятия ШСМ, чем потихонечку занимаемся.

Курс социального мультиданса прошёл 4 занятия из 24, и полные начинашки уже не очень надёжно, но ведут и следуют! Ещё где-нибудь восемь занятий, и можно будет переходить к кругозору, начинать знакомить с конкретными танцами, а там и знакомить с тем, что делают на вечеринках (это системным уровнем выше, и этому тоже нужно учить). Такой скорости обучения танцам ещё не видел, методика использования системного фитнеса таки творит чудеса. Но я бываю не на каждом занятии по танцам. Вчера я принимал четыре защиты эссе по курсу "Системный менеджмент и стратегирование 2019" в одной аудитории, а этот самый мультиданс был в другой аудитории. Начали и закончили практически одновременно. Всё чаще и чаще в Школе идут несколько мероприятий одновременно. Растём.

Три чата трёх студенческих групп из пары вузов, они звенят непрерывно. Плюс чаты групп ШСМ. К каждому студенческому чату добавляется чат преподавательский. А ещё большая группа менти. Работать в этих условиях невозможно, весь день уходит на то, чтобы чатиться. Но это вроде как и есть работа?!

Узнал, что налистники -- это тонкие блины. Когда в Братьях Караваевых нет домашней запеканки (а её нет всё чаще и чаще, но это first choice -- подогреть и с ванильным соусом), то беру их. С латте это очень вкусно!

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216527660878073
2019

lytdybr

Схематизация и рендеринг на разных теориях концептов, фордеф (2011 -- https://ailev.livejournal.com/884842.html, это ещё до нейронных сетей, и даже 2010, где я жалел, что двигаю только по линии theory theory, игнорируя другие когнитивные архитектуры на других теориях концептов, и поминал Витгенштейна, что сегодня закрывается нейросетками -- https://ailev.livejournal.com/884842.html). Это нужно как-то срочно проработать. Я писал об этом в пункте 5 заметок по риторике https://ailev.livejournal.com/1491835.html, а вчера на лаборатории телесного мышления мы добавили схематизацию и рендеринг при работе с человеческим движением: движение в его внутреннем телесном представлении схематизируется во внешнее/схему, в схеме находятся ошибки, а затем исправленная схема рендерится во внутреннее представление и исполняется телом. Это, конечно, происходит в цикле. Дальше открываются огромные перспективы обсуждения того, как именно проходят телесные схематизация и рендеринг (например, какие системы понятий при этом используются — сразу theory theory или возможны промежуточные не слишком рациональные, но более привлекательные для непосредственного восприятия варианты, например prototype theory, лежащая под использованием метафор). Это кладёт рациональную основу для представлений о телесном мышлении.

Ontolog Forum сделал ютьюб-канал: https://www.youtube.com/channel/UCKK2e8NZ9lyLDBpXY18O_Tg -- и там уже 6 видео, в том числе видео доклада John Sowa про knowledge graphs (так сегодня часто начинают называть то, что раньше называли онтологиями или базами знаний), и видео Jans Aasman из AllegroGraph про те же knowledge graphs. И видео открытой дискуссии по knowledge graphs, которую вёл Ken Baclawski. Они там изучают схематизацию в разных вариантах: из текстов и картинок и выработанных из любого сора стихов как сделать схемы (главным образом нейронными сетями, но и прочими подручными средствами), по которым потом хоть как-то рассуждать.

Наш преподаватель онтологики Пион Медведева вчера начала преподавать онтологику в НИУ ВШЭ на магистерской программе "цифровая трансформация образования" для руководителей образования (по факту там все "студенты" уже с высшим образованием, да ещё и начальники). Следом за ней буду преподавать я системное мышление, системный менеджмент и стратегирование, а следом за мной -- Вячеслав Мизгулин системную инженерию. Наш опыт в ШСМ показывает, что после этой последовательности люди вполне успешно проводят программы реорганизации в своих компаниях. Эти магистры, думаю, тоже так смогут. Это линейка по линии "трансформации". А ВШЭ в лице лаборатории с хитрым названием МНУЛ ИССА ФКН НИУ ВШЭ (военные, завидуйте!), https://cs.hse.ru/ai/issa/, привнесёт "цифровость" в эту трансформацию. Нас в этой программе интересует то, что нам самим нужно делать "цифровую трансформацию" (как это сейчас модно называть, но мы сами это не так называем -- мода ведь как возникла, так и пройдёт) в Школе, поэтому мы поучаствуем при этом в тамошних айтишно-образовательных разговорах на фронтире (этих разговоров уже случилось некоторое количество, спасибо Ольге Максименковой и Алексею Незнанову). Идея с использованием MS Teams в Школе идёт как раз оттуда.

Вообще, посты для стратегии ШСМ в части её компьютеризации вот, их хватает:
-- EdTech для blended learning -- https://ailev.livejournal.com/1473691.html
-- Чего мне не хватает в MS Teams -- https://ailev.livejournal.com/1490524.html
-- Киборгизация людей и организаций -- https://ailev.livejournal.com/1488271.html, на базе идей по системной осознанности 2019 -- https://ailev.livejournal.com/1487672.html
-- глоссарий понятий для кейса с вопросами и множеством вариантов ответов https://ailev.livejournal.com/1482241.html (там второй абзац)

Вчера сделали подход к архитектуре предприятия для Школы. Мы не стали его делать в Archi, ибо обсуждение сразу пошло вокруг кейсов/проектов, вокруг которых разворачиваются практики их жизненных циклов. Сходу выделили столько разных сущностей, что на одной архимейт-диаграмме их не отобразишь, а на многих -- внимание будет рассеяно. Поэтому текстом, компактно (хотя без пояснений будет непонятно. Но это ж лабораторный журнал, поэтому не заботимся о понятности для широкой публики. А свои поймут):
-- программа Школы
-- курсы в группах
-- курс онлайн self-paced для одного
-- потоки
-- курсанты (подписчик, абитуриент, курсант, выпускник)
-- преподы
-- эккаунт компании
-- корпоративная группа
-- проекты систем в обеспечении (наше IT и другое оборудование): IT поддержки проектов, вебсайт и т.д.
-- конференция
-- лаборатория (цепочка семинаров, включая методический совет)
-- семинар (исследовательский, методический и т.д.)
-- регулярный класс
-- исследовательская программа
-- широкая аудитория/подписчики
-- менти
-- курсовой проект (например, эссе или ДЗ)
-- доброволец/помощник

Вот эта проблема "непонятности для широкой публики" и "понятности для своих" возникла в самой вроде как попсовой области -- социальных танцев. Тамошняя тусовка в связи с запуском курса интересовалась, чего это я пишу так непонятно: разве мы не хотим популярности? Эти же сложные тексты никто не читает! Ошибочка: разработчики нашего курса мультиданса эти тексты читают. Остальным это может быть неинтересно. Попсовые тексты для широкой публики у нас будут в количестве, попсовые тексты уже сегодня произносят преподаватели текущей группе, а я пишу "документацию разработчика": те сложные тексты, которые обеспечивают простую жизнь изучающим социальный мультиданс. Обучаю не я, обучают преподы — и обучают просто. Я моделирую, и моделирую точно. Это не очень просто, широкой публике не нужно, но для команды курса это необходимо. У нас все ходы записаны. При этом я написал попсовый текст разъяснения про непопсовость, опубликовал там в сообществе: https://vk.com/wall-179019873_316. Попсы и так много, мало качественной непопсы. После чего написал попсовый текст про пенфилдовского человечка и то, что мы на курсах танцев учим мозг -- https://vk.com/wall-179019873_317. За час куча лайков. Но этот текст ничего нового не говорит, просто попсовый пересказ старых идей. Я уж лучше себя не для популяризации/рендеринга приберегу, а для схематизации. Ибо рендеринг, конечно, искусство. Но была бы схема, которую рендерить!

Курс социального мультиданса, кстати, успешно начался -- и в конце двухчасового занятия даже были какие-то успешные попытки ведения-следования в паре у ни разу до того не танцевавших (успех, правда, длился секунд по пять -- сколько удерживалось внимание на мышечной координации "чистого натяга" в теле). Набор идёт до 15 октября, вот ссылка: http://system-school.ru/multidance. Из интересного -- в чате группы появилось замечание о терапевтическом эффекте занятия. Ещё бы! Танцевали мы всего минут пятнадцать из двух часов, остальное время готовили мозг. Мозг вдруг заметил тело, вот телу и полегчало от заботы и внимания ))) Вот тут я написал про гомункулуса Пенфилда и обучение танцам как работу с мозгом: https://vk.com/wall-179019873_317

А ещё открыли регулярный класс системного фитнеса, где можно прийти на одно или несколько двухчасовых занятий в свободном режиме: http://system-school.ru/regular. До этого был такой класс в AfroFusion, потом в Spicy Salsa, и вот теперь в неожиданном месте: в ШСМ. И там на первом же занятии, а потом лаборатории телесного мышления обсуждались и совсем нетанцевальные вещи: например, как системный фитнес помогает вокалу (пришёл педагог по вокалу -- там же тоже мышечная работа, хотя это не совсем привычные мышцы, в гортани явно не бицепсы и трицепсы).
2019

lytdybr

Вчера закончил СМС2019.2 (осталась только защита) -- и очень доволен. Это уже вторая группа, выпускаемая по новому учебнику. Учебник работает, его выпуск оказался правильным делом. Я для себя отметил бы три существенных улучшения: 1. Проектные роли понимаются нынешними выпускниками лучше, чем выпускниками прошлых потоков. Все они перестали откладывать этот материал "на потом" и начинают использовать в повседнемном мышлении. 2. Суть системного мышления (отношения часть-целое, системные уровни) как-то присутствуют в понимании примерно у половины группы. Как ни странно, это успех! Раньше пользование концептом системного уровня было не очень практически у всех. 3. Функциональные объекты против конструктивных понимаются практически всеми и активно используются в описаниях рабочих проектов. В прошлых потоках это был камень преткновения.

Мои курсы в октябре-ноябре:
-- "Системный менеджмент и стратегирование 2019", третий поток, http://system-school.ru/uptodate. Старт уже в это воскресенье, 13 октября 2019, шесть дней по воскресеньям раз в две недели, с 11:30 -- закончим 22 декабря 2019. Первые два дня курса мы разбираемся с системным мышлением (собственными ролями и целевыми системами) на примерах рабочих проектов участников курса. Затем три дня идёт кругозор менеджмента, и ещё день разбираемся со стратегированием (это предпринимательство). А ещё на курсе по вторникам проходят 11 еженедельных семинаров с решением задач. Перед курсом надо читать учебник "Системное мышление 2019" (хотя бы до половины, но большинство курсантов успевают прочесть его перед курсом весь. Этим ШСМ сильно отличается от вузов, где учебник остаётся нечитанным долго -- чуть ли не до самой сессии).
-- "Образование для образованных", один день 26 октября 2019, http://system-school.ru/uptodate. Общий рассказ об идеях "предобучения и подстройки" (https://ailev.livejournal.com/1485511.html), краткая характеристика наших курсов по принципу "предъявите всё меню". Именно на этом курсе я обычно рассказываю о своих последних исследованиях. Например, на этом потоке будет больше свежего материала по системной осознанности (https://ailev.livejournal.com/1487672.html) и киборгизацию в части управления вниманием (https://ailev.livejournal.com/1488271.html).
-- новинка "Машинный интеллект 2019", один день 3 ноября 2019, http://system-school.ru/machine. Это я сделал обзорный курс, в котором будет рассказ непрограммистам (то есть без математики и технических подробностей) о сегодняшнем машинном интеллекте и его использовании. Программа курса с подробной тематикой на странице курса, в ней три крупных блока: про интеллект машинный и биологический, интеллект-стек и применения. Спасибо Сергею Шумскому: если бы не волшебный пендель с его стороны, я бы никогда не сподвигся сделать такой курс. Но вот сделал!

Видео моего доклада по методике обучения всем социальным танцам сразу опубликовано: https://www.youtube.com/watch?v=cGDqLJvmam4. Там пропущено первые пятнадцать минут, но два часа пятнадцать минут таки записалось -- включая демонстрации, которые мне помогала делать Ирина Парамонова. Курс начнётся уже завтра (страница курса с описанием и записью -- http://system-school.ru/multidance, мини-группу планируем закрыть 15 октября, выпуск перед новым годом. Я планирую бывать там на занятиях, хотя и не гарантирую, что каждый раз (я ж там не препод, а методолог). Занятия пока будем вести прямо в помещении школы, на ул. Щипок, 11с1. Кстати, по нашей методике в зале для занятий не требуется зеркал. И мы в таком "беззеркальном обучении танцу" не одиноки, я даже короткий текст про это написал, где цитирую Охада Нахарина: https://vk.com/wall-179019873_313.

Институт образования НИУ ВШЭ готовится выпустить доклад про фреймворк о том, как думать о компетенциях и грамотности. Я не удержался, откомментировал тут: https://www.facebook.com/groups/blended.learning.russia/permalink/2432557766986758/. Вот часть моего там коммента: "Мы обобщили литературу по ватрушкам. В большинстве источников признаётся, что ватрушки делаются с творогом, но изредка встречались авторы, которые предлагали ватрушки делать и картошкой. При этом ватрушки разительно отличались по форме, но непринципиально по технологии изготовления. Авторы предлагают framework для понимания ватрушек, который раз и навсегда поможет цифрово трансформировать деятельность поедателей ватрушек, изготовителей ватрушек, сравнивать ватрушки между собой, кладёт надёжную основу для ресторанной критики. Авторы даже написали письмо в ООН, поскольку считают мнение тамошних экспертов более авторитетным, чем мнение Усть-Урюпинского хлебозавода №2. Теперь все ватрушки мы будем сравнивать по форме и начинке, а вот используемое тесто будем считать отдельным предметом ввиду универсальности его использования и в других контекстах, не только в контексте ватрушкиной начинки". Надо как-нибудь про компетенции сделать сервис генерирования текстов такой же, какой сделали про цифровую трансформацию: http://martynov.info/digital/. Это легко, там вот такой шаблон:


Самая крутая мысль изо всего того, что обсуждалось в последнее время -- это тезис "5. Суть убедительности: работа с разными теориями концептов при движении по спектру формальности мышления" из текста https://ailev.livejournal.com/1491835.html. Добавлю ещё штришок: если генерация по схеме человеческого текста должна как-то делать его убедительным, то схематизация наоборот -- это "разубеждение". Если ты убеждён и упёрт, то ошибок ты у себя в тексте не найдёшь. Схема заведомо менее убеждающа, нежели текст. Она антириторична. В этом её достоинство, она позволяет преодолеть соблазны всяческих cognitive bias, хранит от искушений. Формализация убивает человечность, и это не так плохо. Рендеринг её восстановит. И для обсуждения этого движения по спектру формальности мышления нам нужно использовать разные теории концептов в разных частях спектра мышления. Вполне возможно, что все эти architecture relax в дифференцируемости всего https://ailev.livejournal.com/1464563.html должны быть не в рамках только relax представления theory theory, а должны использовать разные теории концептов. Или наоборот: в этом-то и сила компьютеров, что им не нужно продираться через несколько теорий концептов в части представления смысла -- и это способ компьютера стать умней человека, меньше искажений, связанных с особенностями убеждения именно человека и поэтому необходимость задействования различных механизмов представления знаний, хорошо описываемых различными теориями концептов. Мутное, но очень перспективное направление размышлений.

А ещё нужно думать о каком-то тренажёре по работе с типами, ибо на непривычную для животного мира работу в theory theory мозг людей нужно тренировать. Это просто беда, как трудно с нетренированными. Они-то никаких проблем не чувствуют, но вот я побеседовал с новым набором очников МФТИ -- и в печали. Нужно добавлять дни в курс "Схематизация на салфетке и в уме", и добавлять много-много задач, и разбирать много-много ситуаций. В этом нужна беглость, материал схематизации не осваивается (хотя все выпускники благодарны за то, что курс знакомит с самим существованием материала. Но вот получить навык беглой схематизации на салфетке, и уж тем более в уме -- вот этого курс пока не даёт).
2019

Дискуссия о типах и SysMoLan продолжается

Обсуждение SysMoLan в чате представления жизни типами (https://t.me/typeslife) не утихает.

Философская логика
В частности, там пришёл Brenoritvrezorkre (The name Brenoritvrezorkre is written in Gloatre, a language invented by Vordb Dréagvor Uèzréèvb, https://katab.asia/2018/10/16/zurghtapre-of-cannibals/, Бреноритврезоркре — плохая примета, дурное предзнаменование) и рассказал всем, как нужно заниматься экдурантизмом и пердурантизом в частности и философской логикой в целом (для начала читать 18 томов учебника, вот ссылка на том 18, остальные сами найдёте -- https://b-ok.cc/book/3662367/9d5f0c. Не знаю, насколько знание этих восемнадцати томов может помочь в нашей задаче выразить в типах языка программирования понятия системного подхода в том небольшом объёме, который есть в учебнике (и для начала IEC81346 как подмножество этих понятий. Хотя это я лукавлю, стандарт-то большой и заковыристый, понятий там предостаточно). Знание этих восемнадцати томов учебника может помочь IMHO примерно так же, как знание всех томов Кнута может помогает программистам в их работе. И для меня неважно абсолютно, что такое possible worlds в логическом формализме и какая там история их создания. Для меня важно ровно то, что я могу при помощи possible worlds принимать решения в своём проекте: говорить о том, какая именно модель будет реализовываться и какие последствия будут от тех или иных моих решений, и как связаны мои планы и актуальное состояние. Абсолютно прикладное использование, реализация прагматического поворота в философии. Нет использования — не нужно обсуждать этот формализм, есть использование — нужно обсуждать.

Тем не менее, какое-то знание философской логики всё-таки помогает чуток разобраться. Скажем, меня прежде всего волнует описание физического мира в первую очередь, и в концептах системного подхода, а не описание описаний в любых концептах (например, при помощи очень часто встречающихся в IT URI и даже URL). Поэтому у меня ключевой вопрос про моделирование IEC81436, где в том числе обсуждается вопрос привязки документов к системам, а у justy_tylor ключевой вопрос про работу с документами без их привязки к системам.

Конечно, любое описание деталей Боинга (например, по три описания на каждую деталь — их сразу будет 18млн.) будет иметь URI и даже URL. Но я просто не хочу забывать, что это всё описания каких-то деталей Боинга. И идентификация по URI мне мало даёт понимания, где во вселенной мне искать эту деталь, часть чего она и для чего используется. Ибо URI это только про описания, про сферические информационные системы-в-вакууме. Я же изначально задаюсь вопросом, информация о чём в этих информационных системах. У меня не логистическая задача, а содержательная: мне ж нужно методы работы не с описаниями брать, а методы работы с domain.

Да, я согласен, что управление конфигурацией это смежная дисциплина: появление и трансформация объектов в ответственности инженеров, а уже учёт появившегося и логистика это сразу объект менеджеров. Но считать, что всё сводится только к информационной стороне вопроса я не готов. Из коробки должно быть отношение representation к физическому миру.

Так что для меня экстенсионализм про вот это, и поэтому я как-то готов обсуждать и экстенсионализм (о котором мы знаем именно из учебников философской логики).

Дальше там был короткий спор про философию как таковую (моё отношение к философии как к художественной литературе, особенно в стране победившей истории философии вместо философии, см. "О философах как властителях душ" https://ailev.livejournal.com/1128233.html и там дальше про этих властителей дум роскошные комменты). Но это всё было сочтено оффтопом к теме чата.

Естественный язык против формул
Ещё темой было использование естественного языка -- почему мы не можем от него отказаться и говорить только формулами. [байка он] Лет так пять назад я попал на конференцию по аналитической философии, делал это руководитель логико-философского кружка ВШЭ Виктор Горбунов. Он сильно удивлялся, откуда инженеры знают про possible world и Дэвида Льюиса. Но занятно было другое: шли обычные для конференции разговоры-разговоры разных докладчиков, не произносилось ни одной формулы, всё как обычно. Но вдруг кто-то из зала сказал: "я, кажется, понял!". Он вышел к доске и исписал в гробовой тишине всю доску формулами. Ему поправили из зала одну ошибку (даже не ошибку — он мелом плохо нарисовал точку над одним из квадратиков), и дальше до конца дня ни в речах, ни на доске никаких формул не было. [байка офф]

У каждого человека свои представления в голове об уровне формализма, на котором он хочет работать. И работать нужно на полном спектре мышления, а не всё время "в формулах". Фишка в том, чтобы двигаться по спектру формальности мышления, а не просто работать в рамках одного формализма всё время (у меня про это много больше в книжке "Визуальное мышление", https://ridero.ru/books/vizualnoe_myshlenie/ или её можно взять бесплатно в info чата, можно посмотреть ещё вышедшие до этой книжки короткие тексты по развитию мышления -- https://ailev.livejournal.com/1425003.html и про творчество в системном мышлении https://ailev.livejournal.com/1425331.html).

На помянутой в байке конференции доклады были все об идеях Крипке, Льюиса и их коллег, но без формул. С формулами была только вот та самая вставка. Как я понимаю, людей на логическом отделении философского факультета учат отождествлять текст и формулы в обе стороны — формализовывать и деформализовывать. Поэтому они не стесняются говорить о формальном и текстом тоже, это абсолютно нормально. С архитектурными моделями точно так же: Дэвид Файерсмит предупреждает всех, что из архитектурной документации ни в коем случае не должен уходить текст и оставаться только модели на формальных языках моделирования -- ибо даже сам смысл выбора тех, а не иных способов моделирования (viewpoints) должен обосновываться текстом и представляться в составе документации, равно как и самое верхнеуровневое описание в виде "архитектурного эссе".

Почему для работы с формальными системами (особенно, если их несколько одновременно в рассмотрении) нужно иметь и естественный язык — об этом любит рассуждать John Sowa (родоначальник computational ontology, он и до сих пор бодрый дядька, недавно его чуть в сообществе Ontolog FORUM не забанили — он там сильно наехал на создателей очередного всеобщего онтологического ISO по поводу их заблуждений, там работала уже административная машинка и голосовательные популистские механизмы, а John "вынул гранату, кинул в окно — дедушка старый, ему всё равно". Я там член попечительского совета, с интересом наблюдал за этой историей борьбы здравого смысла с бюрократической политкорректностью. Онтологии дело нервное!). Так что формализмы и естественный язык нормально сосуществуют, и это не бага, это фишка/фича.

Народные онтологии
Обсуждали в том числе и использование народной (из общепринятых словарей) онтологии -- ибо были сделаны попытки использования теории типов с интерпретацией на базе "просто из вебстера". то у меня превращается. Вопрос на практике возник из непонимания, как делать системы тегов: на основе какой-то таксономии (которые вроде бы хоть как-то логически выверялись), или на основе народных представлений ad hoc (folksonomy). Любили при этом поговорить о фасетной классификации и всяких подобных материях. Потом оказалось, что:
а) предмет интереса во времени плывёт, и из старых текстов берут вовсе не ту информацию, по которой они были протегированы
б) полнотекстовый поиск заменяет все эти теги

Онтологии — это просто добавление к таксономиям разных типов отношений. Дальше мы уже обсуждали тут, что Грубер определил computational ontology как формализацию для концептуализации предметной области, но его поправили, заявив, что это должна быть shared концептуализация — то есть речь идёт о разделяемой (каким-то сообществом, folk) картине мира, а не любой картине мира.

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

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

У нас совершенно конкретная предметная область. И проход улучшения феноменологии для концептов из учебника был, это несколько лет обсуждалось в сообщстве Русского отделения INCOSE, обкатывалось на разных учебных курсах, понимание уточнялось и по возможности согласовывалось с современными онтологическими представлениями (в том числе представлениями из книжки BORO). Формализом там, конечно, и не пахнет, ну так я ж особо и не настаиваю — просто потихоньку обсуждаются разные уровни этого формализма (там ведь эти формализмы до самого низа, и всегда будут проблемы, не хотелось бы их прихватывать, начиная от уровня проблем оснований математики).

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

Альтернативный подход -- понятия системного мышления нужно считать входящими в состав upper ontology "из коробки", и мэппить внесистемные понятия нужно не сначала к понятиям более общей онтологики, а только потом к понятиям системного мышления, а сразу к понятиям системного мышления. И понятия системного мышления базируются на более общих онтологических понятиях, но не образуют совсем уж отдельный уровень.

Я придерживаюсь сейчас этой позиции, примерно это же предложил Matthew West с его HQDM в альтернативу онтологии ISO15926, а также некоторые другие неожиданные товарищи (типа СМД-методологов, регулярно обсуждающих этот вопрос -- ибо для них в силу их гуманитарной ориентированности концепты upper ontology как-то неразрывно связаны с рассуждениями о боге, но хочется иметь светскую upper ontology, для чего и интересует системный подход как основа светской онтологии -- это эхо, конечно, чисто метафизической дискуссии, привет из прошлого. Тем не менее, это пример того, что желающих иметь системную upper ontology "из коробки" достаточно много и кроме меня и Matthew West).

Так что я за то, чтобы делать сразу системный моделер, а не сначала общеонтологический, а затем на нём системную специализацию. То есть не моделер типа Protege-дляOWL-только-не-OWL-а-лучше, или моделер для MOF-UML, а уж потом их специализировать до моделера SysMoLan, а сразу моделер SysMoLan.

И да, я понимаю, что работать в этом моделере придётся с самыми разными описаниями. Но нельзя терять тот аспект, что эти описания привязываются друг ко другу, и в конечном итоге к системам. Поэтому имена, к которым все эти описания привязываются в конечном итоге, важны. Стандарт IEC81346 даёт best practices в том, как делать имена для систем, и даже даёт best practices, как делать имена для документации этих систем (хотя этот вопрос там и не главный и значительно хуже проработан. Может, в последние годы там что-то изменилось с именами описаний, тоже вышли какие-нибудь практические рекомендации). Конечно, любое описание деталей Боинга (например, по три описания на каждую деталь — их сразу будет 18млн.) будет иметь URI и даже URL. Но я просто не хочу забывать, что это всё описания каких-то деталей Боинга. И идентификация по URI мне мало даёт понимания, где во вселенной мне искать эту деталь, часть чего она и для чего используется. Ибо URI это только про описания, про сферические информационные системы-в-вакууме. Я же изначально задаюсь вопросом, информация о чём в этих информационных системах. У меня не логистическая задача, а содержательная: мне ж нужно методы работы не с описаниями брать, а методы работы с domain.

Да, я согласен, что управление конфигурацией это смежная дисциплина: появление и трансформация объектов в ответственности инженеров, а уже учёт появившегося и логистика это сразу объект менеджеров. Но считать, что всё сводится только к информационной стороне вопроса я не готов. Из коробки должно быть отношение representation к физическому миру.

Дальше было заявление justy_tylor "Тут у нас разница в интересах. Если придерживаться "онтологической" терминологии, то мой интерес это foundational ontology. Я считаю, что только построив foundational, и подтвердив её удобство в мэппинге между используемыми на практике представлениями данных и modeling approaches, можно построить приемлемую upper ontology над ними. Потому что обратный подход (upper без приличной foundational) мы уже наблюдали, в том числе, в ISO 15926, и получались какие-то untested beliefs. Поэтому вопросами upper я не занимаюсь - рано".

Для меня это уже было понятно, для меня это звучит как:
1. Foundational ontology для моделирования описаний, но не для моделирования мира в целом
2. Foundational ontology для upper ontology из классической онтологики, без акцентов на системном подходе.

Это выборы justy_tylor в уже высказанной развилке: системное мышление в рамках upper ontology или системное мышление в рамках middle ontology. При этом я с тяжёлым вздохом говорю, что ни upper, ни systems middle ontology действительно ни при чём при выборе foundational.

Но дальше есть некоторое соображение. Я в своё время начинал работать в исследовательском вычислительном центре, где разрабатывалось много-много компиляторов, языков программирования и т.д.. И было поэтому много-много людей, которые занимались формальной семантикой языков. И почему-то успех был в ЖЦ, когда создавалось полностью неформальное ad hoc решение на диких эвристиках, и эти дикие эвристики вдруг оказывались хорошими, под них люди кряхтели и подыскивали формализм, потом подхакивали эту эвристику, чтобы не поломать её об формализм и дальше получали формальное успешное решение. А вот где сначала был формализм, потом попытки его "прикласть" через создание "прикладного языка с формализом внутри" — вот тут всё плохо было обычно. Учёные восхищались, система входила во все учебники как "удивительно простая и элегантная, решение всех проблем" — но популярности эта "элегантность и компактность формализма" явно не добавляла. Монады хаскела можно отнести к очередным примерам (пока хаскел с 1990 года уже 30 лет "продолжает набирать популярность", успел стать суперпопулярным и потом умереть тот же эклектичный перл, родившийся примерно в то же время, в 1987 году, а Питон от 1989 года успел стать суперпопулярным и не умереть). Оказывается, формализмы и обильная математика под языками программирования не являются гарантами их популярности -- и даже наоборот, как-то коррелируют с непопулярностью!

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

ISO 15926 рухнул IMHO ровно из-за выбора мощного рудиментарного формализма триплами. Триплами можно что-то выразить на очень низком уровне, это foundational ассемблер и должен быть очень глубоко под капотом. До удобных шаблонов с n-арностью в выражении мира мир ISO15926 так и не дорос, ло. Если бы сразу были шаблоны, то всё ещё могло бы состояться. А потом эти шаблоны бы посадили на какой-нибудь формализм, а хоть и те же триплы. Но потом, когда бы всё уже было понятно как устроено и был бы опыт моделирования. А иначе — 18 триплов, описывающих величину с указанием единицы измерения, я помню (). И никакого практического способа указать "x=5кг" вот этими вот пятью символами, ибо "шаблоны и как их выразить, чтобы не порушить формализм" было выдумано явно несвоевременно.

Прорывы типа реляционного формального исчисления и SQL — ну, это ошибка выжившего. Всегда есть исключения, которые на слуху именно потому, что они выжили. За счёт чего они выжили? Я высказывал какие-то свои соображения по поводу де-факто разделения языков управления данными и языка вычислений над данными. Это зыбкая граница в computer science и даже software engineering, но уж какая есть.

Так что я интересуюсь в чате у знатоков языков программирования: как принято типами языков программирования выражать онтологии? А мне отвечают: сначала нужно иметь foundational ontology, чтобы выражать онтологические upper ontology типы, для этого нужно придумать формализм, для него сделать солвер, и уж потом это всё выражать в Julia. Я время от времени задаю вопрос про "можно ли прямо типами языка и структурами данных Julia?" и получаю ответ, что нет — ибо должен быть не GPL+eDSL с моими типами и структурами данных, а GPL+язык запросов+солвер-с-формализом. Но поскольку время от времени появляются разные варианты ответов, то я продолжаю внимательно слушать.

Дискуссия дальше идёт о том, нужна ли вообще upper ontology или сразу микротеории без upper (но само понятие микротеории тогда как выражать? из какой оно онтологии?), а foundational ontology это и есть "новый upper" (у байесовцев в ML это называется innate priors — те концепты, что мы не можем выучить из мира и таки должны задать "в аппаратуре/алгоритме обучения"). Я готов и это обсуждение поддержать. Но моя мысль, что вот это "реализованное в аппаратуре" должно бы включать мир (физичный), модели (описание) и тех, кто описывает (агентов с их предпочтениями в интересах и намерениями по изменению мира, для чего им и нужны модели). А поскольку мир и агентов и описания, то можно смело туда сразу записывать и системный подход, как уточняющий тем, как управлять вниманием в мире. Управление вниманием, системное мышление из менеджерских/логистических краёв, оно не про трансформации.

Собственно, про это "управление вниманием", "менеджерское/логистическое" программирование для того, чтобы предоставить данные для трансформации возникло как моя реакция на реплику justy_tylor по поводу задач, которые он считает важным для языка работы с foundational ontology: "осуществление логического вывода (прямо в этом представлении), двухсторонний мэппинг с другими представлениями (оптимизированными под конкретные предметки), визуализация (таблицы, деревья, диаграммы), интеграция фрагментов описаний, разрешение конфликтов интеграции (как автоматически на машинном уровне, так и в diff-merge утилитах с участием человека), и так далее".

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

Содержательные задачи не требуют логического вывода, они лучше решаются по другому. Это для логистики (выбрать те данные, с которыми потом будет что-то интересное делаться) важно.

То есть получается, что есть один язык для собственно работы (какая-нибудь Julia), а все эти выводы-мэппинги и т.д. это управление памятью и вниманием над памятью (какой-нибудь SQL).

И все эти заходы на морфизмы — у меня прямо таки все кейсы перед глазами, когда менеджеры рассуждают про строительство предприятий, стараясь абстрагироваться, спички эти предприятия выпускают, вебсайты, или ракеты на Марс. Опыт показывает, что в итоге предприятие работает очень хорошо, пока у инвестора деньги не кончаются. Если строишь завод самолётов, то завод будет работать хорошо, только самолёты могут не летать )))

Надо будет подумать. Современный AI, конечно, все задачи сводит к управлению вниманием и памятью сегодня, но в знаниях не всё можно "вспомнить" или "найти где лежит". Чтобы в базе данных что-то появилось, туда нужно что-то класть. Языки запросов, как известно, базу данных не меняют, почему их и называют языками запросов. Это потом почему-то хочется туда и запись информации вставить. Всегда хочется.

Надо будет ещё подумать, почему эта формализация мне менеджеров против инженеров напоминает. При этом абсолютно понятно, что для логистики "что угодно достаём откуда угодно и транспортируем в заданном формате куда угодно, гарантируя непотерю содержания" и работы "делаем преобразования" требуются разные архитектуры, разные языки, разные способы работы. PLM и мэппинг — это про логистику, это ж lifecycle management, менеджмент. В принципе, инженер без логистики ничего делать не может (задачу он получает, входные данные и материалы получает, выход тоже у него уходит куда-то в другое место). Но разделение "логистика/внимание vs трансформация" при всей его неуловимости в области информационных технологий и математике по крайней мере хоть как-то объясняет мне происходящее. Разделение труда: одни на фортране считают режимы, а другие на логическом языке SQL (pun intended) выдирают из общих описаний материал, на котором первые считают эти самые режимы. Все довольны, всем счастье. Языки не представления знаний, а управления данными и инженерные языки для предметных вычислений. Хм. Как-то подозрительно всё сходится.

Так что нужно сделать два языка, как-то связанных друг с другом, или один мультипарадигмальный язык, в котором есть и язык логического вывода для управления вниманием/данными, и язык общего программирования для трансформаций данных. Общий язык для менеджеров данных и инженеров предметной области. Потому как разрыв мной ощущается где-то в этом месте: базы данных с языками запросов и по сопричастности логические языки и классические языки представления знаний с FOL/HOL в основе против каких-то специфичных преобразований на GPL и тогда логика в GPL появляется только для доказательств правильности (иначе все умрут, если логикой не долько добывать данные и доставлять их на обработку, но и обрабатывать/трансформировать/что-то с ними вычислять). И между этими языками вроде как неминуемые всякие ORM (object-relational mapping) и прочие GPL-logic mappings, которые я бы и хотел исключить -- почему и затеял всю эту дискуссию.

Ну вот поиск метафоры это хорошо, но всё одно меня не греет. Если мэппинг, то скажут что "берите функциональный язык, и мэпьте". На уровне приложений из метафор есть search (в том числе поиск решения в пространстве решений), а есть learn как вычисление подходящего ответа по выученному ранее (человеком, который потом это выученное в своём мозгу закодировал как модель в GPL или нейронной сеткой в компьютере, которая сама учится на примерах).

Грубо говоря есть какие-то CAD-с-редакторами и солверами разных domain, где так или иначе что-то типа Архимейта или 3D-моделера, а есть PLM с "базой данных и логистикой", куда все эти CAD втыкаются. Это общая структура разработки чего угодно, даже программного кода (есть IDE и есть Git). Я немного писал об этом в https://ailev.livejournal.com/1277009.html, и даже EduTech для образования может быть описана таким образом, https://ailev.livejournal.com/1473691.html.

И у меня гипотеза, что CAD будет всегда с GPL внутри (когда-то в AutoCAD был даже лисп, но потом всё нормализовалось). И IDE будут с GPL внутри, ибо "всякая достаточно большая программа содержит в себе кривой и плохой common lisp", уж так получается. А в PLM всегда важен мэппинг, чтобы взять данные из одного вида CAD и послать их часть в другой CAD на просмотр и редактирование (руками или программно — это неважно).

Фишка в том, что CAD и PLM не живут друг без друга, поэтому начинаем с моделера-CAD, а заканчиваем всё одно PLM-базой данных с кучей экспорт-импортов, или наоборот — начинаем вроде как с мэппинга-в-PLM, а заканчиваем сначала неизбежной визуализацией, а потом и обязательно редактированием WYSIWYG и для этого всё одно солвером, то есть приходим к группе CAD для разных domain, отражённых в начальной PLM-базе.

Если начинать с мэппинга, то сразу вопрос: а где брать системные модели, к которым мэппить всё остальное? Нужен таки моделер перед тем как к нему мэппить. Моя идея взять IDE типа Вижуал Студия и считать её моделером, если модель будет в текстовом eDSL системного моделирования. А потом да, к ней мэппинг, когда эта модель уже есть и есть средства её отображения. Прошлый вариант ТЗ уж как я его понимаю я формулировал в https://ailev.livejournal.com/1488488.html — и более точно пока сформулировать не могу. После этого текста из нового пока у меня только эта мысль про различие eDSL для управления данными (и представление знаний вроде как идёт сюда, тут все интеграции и прочие "семантические технологии") и для работы с данными (все матлабы и CAD вроде как тут, а логические языки не тут) с какими-то "мэпперами" из типов/foundational ontology языка рабочего языка программирования в типы/foundational ontology менеджерской базы данных, я продолжаю эту мысль думать дальше, она интересна. С этой мыслью domain онтологической работы и по сопричастности системной работы представляется мне немного другим. Трансдисциплины (онтологика и представление знаний, системное мышление) для управления вниманием, а оптимизация, порождение и прочее такое делается на других дисциплинах их eDSL.

Итого: Чтобы выразить в каких-то типах GPL (языка программирования) типы системного мышления, нужно сделать какой-то язык запросов/управления данными для представления знаний в языках программирования (языкGPL-с-языком-запросов, и с этим ещё нужно будет поразбираться — мне это место у justy_tylor мутно). В этом языке запросов/управления данными будут делаться запросы на выборки из представления знаний о мире в каком-то графе, а для этого будет реализован солвер, предположительно для FOL или теоркатегорный или ещё какой формальный (тут тоже мутно, мнения различаются). И вот для этого солвера нам нужно предложить формализацию данных для вычислений этого солвера, связав её как-то с понятиями системного подхода.

Для меня это звучит более понятно как поиск foundational ontology для upper ontology из учебника. И для foundational ontology предполагается, что можно сделать движок/солвер/реализацию языка запросов и хранилище данных для этих запросов (но это не предполагает вычислений в инженерном смысле, а просто "управление данными"), а upper ontology из учебника при этом как-то закодировать в виде данных для этого движка. Такой подход подразумевает, что математически все запросы смогут быть исполненными (хотя гарантий времени исполнения и возможности оптимизации запросов не даёт никто, и это сильно меня напрягает: похожие проекты по формализации с похожей архитектурой все заканчивались печально, типа тех же разработок с BDI и агентским подходом и родственниками — математически там было всё ОК, но вот пользоваться софтом там было невозможно).

Ещё в чате тут помянули агентский подход с BDI и его многочисленными родственниками и неудачку с использованием логик в агентском подходе для содержательной работы (символический искусственный интеллект от забора до обеда и неминуемая неудачка в связи с этим). Но не буду цитировать, ищите в чате сами на "BDI".

Теория прототипов, трансформеры и успех языков программирования
justy_tylor заметил, что "помимо упоминавшихся BORO, ISO 15926, Gellish, HQDM, а также книжки @ailevenchuk и мелькающей в последнее время таксономии IEC 81346, для понимания рассматриваемых тем неплохо бы прочитать:
1. Три тома материалов HOPL. https://en.wikipedia.org/wiki/History_of_Programming_Languages
2. Пару книг Лакоффа по когнитивной лингвистике: George Lakoff and Mark Johnson "Metaphors We Live By", George Lakoff "Women, Fire, and Dangerous Things: What Categories Reveal About the Mind".

Лакофф затем, что популярно описывает явления вроде "базового уровня восприятия", понимание которых является ключевым для создания эффективных EDSL".

Я нашёл это замечание очень интересным. Типы и FOL из theory theory поддерживают медленное мышление по Канеману, а прототипы (Лакофф! Первичное восприятие!) — быстрое. Если говорить об успехе в рамках теории percieved cognitive load, то эту нагрузку, получается, нужно считать не в типах/классах из theory theory, а в прототипах (https://plato.stanford.edu/entries/concepts/ -- про теории понятий, в том числе theory theory и prototypes, хотя там есть и другие). То есть в спектре мышления по мере движения по этому спектру в пространстве смыслов формализация не просто relax в рамках theory theory по мере движения влево, но и меняется её способ, и всякие "интуиции" по поводу тех же типов/классов (и отнесения к типам/классам) формулируются как прототипы для типов/классов. Это, конечно, гипотеза, но покрутить её было бы весьма любопытно. Если (как предложила @pionmedvedeva в какой-то момент) у нас таки спектр формальности, т.е. в середине там гибриды медленного и быстрого мышления, то по факту у нас где-то в середине будут и гибриды theory theory и теории прототипов.

Сам заход на то, что нужно для создания удобного eDSL поразбираться с мышлением, мне кажется важным. Понятно, что и IEC81346, и понятия из учебника системного мышления — они все из theory theory. И предлагаемые для них варианты концептуализации (предлагаемые foundational ontology) тоже из theory theory. Что про эти навороты будут думать люди, которые не прошли десятилетнего математико-логического тренинга (а, например, прошли пятилетний подобный тренинг) — это в дискуссии только разок мелькало, когда про когнитивную нагрузку говорили и в том числе теорию piercieved cognitive load как барьер к массовому распространению.

Очень, очень интересно. Это для меня вторая интересная мысль из дискуссии, после мысли про язык представления знаний как язык логистический для управления вниманием на какой-то памяти, но не трансформации. [при этом, конечно, сразу захочется его иметь и для трансформации, и попытки делать чисто логические вычисления для меня становятся чем-то типа недифференцируемого варианта трансформер-архитектуры для нейронный сетей: выкидывается всё, кроме работы внимания — https://medium.com/inside-machine-learning/what-is-a-transformer-d07dd1fbec04, и я понимаю, что это аналогия полная шапкозакидательства, но мы ж тут Лакоффа и метафоры обсуждаем, или что?! )))]

Логическое моделирование в системной инженерии
Вообще, должен сказать, что логическое моделирование в системной инженерии по факту есть (хотя его и нет — занимаются им единицы инженеров, это местный курьёз, который подаётся как мейнстрим примерно так же, как когда-то подавался пролог). Это OCL к UML, для которого есть профиль SysML. Он насквозь объект-ориентирован, но задним числом через UML и MOF к нему был приделан логический формализм, и есть текстовый язык OCL, который может выразить всё, что выражается тамошними диаграммками, плюс ещё много чего логического. Мне не нравится SysML, ибо системности и онтологичности в нём ноль. И GPL там совсем не предусмотрен. Но есть несколько моделеров (дико дорогих, но и опенсорс что-то есть). Есть и похожие решения с другими архитектурными языками, не опирающиеся на какие-то стандарты. Но они также не слишком системны. Так что ссылок не даю. Это если вы считаете, что я про них не знаю. У меня десять лет назад вышла статья в INCOSE INSIGHT — я там ругаюсь на SysML, https://levenchuk.com/2009/12/08/sysml-is-the-point-of-departure-for-mbse-not-the-destination/