Ровно восемь лет назад, 16 сентября 2014 года я планировал написать три тома по системной инженерии, https://ailev.livejournal.com/1136987.html. И по факту я удерживаю внимание на этом проекте до сих пор, хотя там явно уже не три тома, сильно побольше (первый том 2014 года по системноинженерному мышлению превратился в два тома ПСМ и Методология чисто по ограничениям объёма и были переписаны 7 раз, второй том про практики системной инженерии (которые в мире изменились с 2014 года) только-только написан, а третий том по разнообразию инженерных систем превращается в целую россыпь -- сейчас переписываю системный менеджмент как инженерию предприятия, мастерство обучать образованных пойдёт в переписку следующим, а дальше как в этом посте 2014 года написано, надеемся на студентов, которые будут писать все эти прикладные курсы. И ещё остаётся "Образование для образованных", где описывается мыслительное мастерство полного интеллект-стека (в 2014 году мои мысли так далеко не залетали). План 2014 года был "по одному тому в год", получилось сильно медленней, я существенно недооценил количество переписываний этих томиков и объем материала для каждого из них. По факту я вышел на некоторое плато: поддерживать актуальность всех этих уже написанных томиков как раз и занимает full time. Поэтому в 2022 году мои планы более скромны: ухитряться сохранять все эти томики SoTA и успевать согласовывать с томиками, которые пишу не я (онтологика и коммуникации, собранность, системное саморазвитие/инженерия личности, системный фитнес и системный мультиданс, и т.д.).
Операционный менеджмент можно грубо разделить на менеджмент разработки (development, knowledge work management) и менеджмент производства (DevOps, manufacturing), и это деление вроде как общепринято. Но есть ведь ещё и архитектура, и она "про другое", про оргразвитие. Надо подумать, что там за менеджмент. И есть product management, который отвечает за business case вместе с developers. Так что тут нужно будет поразбираться, но сразу становятся понятными все эти разговоры про "только не перепутайте канбан для производства по идеям Тойоты и канбан для разработки, ибо оно ж всё совсем разное" (но всё одно путают, в TameFlow эту путаницу подчёркивают), а также понятны становятся фразы Элона Маска про "ракету спроектировать и построить -- ерунда, а вот ракетный завод -- это сложно" (грубо говоря, "разработка и архитектура это просто, а вот DevOps с его тёмным и холодным производством и связью разработчиков с клиентом через него -- проблемка"). От разделения "инженеры, менеджеры, предприниматели" избавились, текущее деление оказывается более сущностным -- неявное разделение становится явным не только у машиностроителей или программистов, но и вообще у всех, даже в ШСМ (у нас DevOps -- это собственно обучение, оно должно быть автоматизировано и проводиться в лучшем случае "сержантами" по сержантскому методу по максимуму, а вот разработка пока не автоматизируется. Тут богатое поле для рассуждений). Примерно такие же затыки с теми же танцами -- DevOps место трудное, зашифровывается как "сколько времени вы готовы потратить на танцы, так вы и будете танцевать -- хорошо или плохо. Но не факт, что много потраченного времени конвертируются в хорошие танцы", и дальше идёт размахивание руками вместо явных объяснений, почему так. Так что текущее исследование по курсу менеджмента -- это разборки даже не столько с менеджментом в development, сколько разборки с менеджментом инженерии в целом: менеджмент (developers+architects+DevOps)+менеджмент цепочки создания+учёт в менеджменте стратегирования по части продукта с его business case + пока не обсуждаемый в инженерии маркетинг (ибо это инженерия клиентуры). Вот описание этой сложной картинки -- это и есть общее содержание курса менеджмента, обзор надо дать в первой главе. Так что я пока в исследованиях: понятно, какие проблемы и примерно понятно по какой линии нужно искать внятные объяснения, осталось провести исследование, подобрать литературу и изложить внятно. И всё это месяца за два. Это всё более базовые и насущные вопросы, чем текущие "психологические" обсуждалки лидерства по линии "что делать с выгораниями" и "почему творчество и инициатива падают при переходе на удалёнку, как вынуть людей назад из дома". Если люди проявляют невиданное творчество в криво организованном предприятии, то предприятию всё одно крышка, если только инвесторы не прожигают деньги, или случайно не вышли шагом раньше на бурно растущий рынок и появилась денежная подушка, которую можно с аппетитом проесть за год-другой.
В чате "Типы в языках программирования, моделирования, представления знаний" прошёл материал по книжке "Data and Reality", 1979 -- с https://t.me/typeslife/16777. Обращалось внимание на фразу "Once more: we are not modeling reality, but the way information about reality is processed, by people. — Bill Kent", книга обсуждается в https://buttondown.email/hillelwayne/archive/why-you-should-read-data-and-reality/. Вот что я там написал: "Это всё про онтологию (как определять и описывать объекты в мире "статично", включая описание изменений в мире как выход за пределы, например, пятой нормальной формы в реляционных описаниях в шестую нормальную форму), а сама фраза — про эпистемологию (как вы узнаёте, что людям надо описывать эти объекты вот так, а не другие объекты, и по-другому, и поэтому появляется динамика смены описаний). Computational ontology шла очень интересным путём. Потом появился OWL, идея, что "семантический веб спасёт мир" — и эта неудачная имплементация идеи выкинула всю идею в целом. Собственно, когда я говорил, что неплохо бы сделать сообщество по обсуждению концептуального моделирования (онтологические штудии ещё и вот так называются) без OWL или SQL, а прямо в языках программирования — то вот это сообщество "Типы в языках программирования, моделирования и языках представления знаний" и было создано. Так что книжка да, в самое яблочко. 1979 год, в этом году не все базы данных были ещё реляционными, были ещё CODASYL и "деревянные", и ожидались ещё варианты (все эти MongoDB пришли, конечно, но сильно позже — на некоторое время реляционки таки всех съели). OWL всех соблазнил где-то в 2004 году, и все эти рассуждения по линии, которая была в книжке Bill Kent с тех пор заглохли. Когда вроде удалось победить идею, что OWL решит все проблемы, пришли нейронные сети. И всё опять заглохло с типами — "типы вам откроет нейронная сеть" )))".
Очередное обсуждение байесианства по сравнению с фриквентизмом (и лайклихудизмом, https://osf.io/4bxke/download/), а я ещё добавляю квантовоподобность случилась в сообществе Julia с https://t.me/JuliaLanguage/29118. Я добавляю ещё "Тут ещё разница между дискриминационными и порождающими (generative) моделями, и там тоже свои особенности. Ибо для жизни в мире нужны предсказания будущих состояний при определённых условиях, а они даются порождающими моделями, а когда обсуждают "разные статистики" то почему-то ограничиваются дискриминационными моделями — у них сильно ограниченная роль. Но это, конечно, уже выходит в дополнительные обсуждения целей, для которых вся эта разная статистика используется. https://en.wikipedia.org/wiki/Generative_model", мне отвечают "Вот, например, есть у нас какой-нибудь тест когнитивных способностей, и мы его хотим применить для определения стадии болезни, как там нам поможет генеративная модель?", я на это "Системный подход: шагаем вверх (а не вниз) от уровня этой ситуации — зачем нам определять стадию болезни? Скорее всего, это часть какой-то порождающей модели, "если стадия такая-то, то жди такого-то развития событий". Ход тут на то, что каждый раз нужно сразу работать с порождением. Хассабис про это говорил, что end-to-end learning каждый раз оказывается точнее, чем когда мы передаём информацию от одного частного вычислителя другому", мне уточняют "Ну хорошо, приходит человек к врачу, говорит у меня что-то проблемы с памятью, врач ему назначает нейропсихологический тест. Если у него стадия номер 1 (условно) человеку можно предложить поучаствовать в клиническом испытании нового лекарства, если стадия номер 2 то только паллиативное лечение", я в ответ "Это краткий пересказ законодательства/административной процедуры. Если участвуют законы, то выполнение религиозных предписаний (вообще без обоснований), приказов начальников (вообще без обоснований), произвольно выбранных классификаций (вообще без оснований) вполне оправдано. Если попал в пенсионный возраст 60 лет, то тебе платят из бюджета. Если перенесли "по политическим причинам" возраст на 65 лет — не платят. Обоснование? Произвольно придуманный закон, административное принуждение. Значительная часть медицины — это организация такого принуждения, к науке, исследованиям и прочему такому отношения не имеет. Так что сами разбирайтесь со своими администраторами, я тут про жизнь, а не произвольно придуманные правила отнесения к таксонам". Понятное дело, что дальше была повторена позиция "наше программистское дело малое: реализовать вычисления по административной процедуре, наука не волнует, моделируем жизнь в её административной данности". Я отвечал "Да люди с чем только не соглашаются в связи с административными процедурами — у меня про это текст есть, про симпатическую магию. Скажем, посчитал фриквентистски-административно, и считаешь, что в реальности все вдруг вылечиваться начнут, независимо от кривизны модели. Вот текст: https://ailev.livejournal.com/1644996.html. Но это уже не про Julia. Julia и хорошую модель посчитает, и плохую. Топор должен быть острым, а по полену его, по пальцу или по чужой голове — это отдельный вопрос".
Чтобы не терялось (уже несколько раз искал): Linearity of quantum representation: exponential speed up for biological functioning -- это в https://www.sciencedirect.com/science/article/pii/S0303264720301994. One of the advantages of this representation is its linearity. The quantum state space is a complex Hilbert space and dynamical equations are linear differential equations. For finite dimensional state spaces, these are just ordinary differential equations with complex coefficients (so, the reader should not be afraid of such pathetic names as Schrödinger, von Neumann, or Gorini–Kossakowski–Sudarshan–Lindblad equations). The classical biophysical dynamics beyond the quantum information representation is typically nonlinear and very complicated. The use of the linear space representation simplifies the processing structure. There are two viewpoints on this simplification, external and internal. The first one is simplification of mathematical modeling, i.e., simplification of study of bioprocesses (by us, external observers). The second one is more delicate and interesting. We have already pointed to one important specialty of applications of the quantum theory to biology. Here, systems can perform self-observations. So, in the process of evolution say a cell can “learn” via such self-observations that it is computationally profitable to use the linear quantum-like representation. And now, we come to the main advantage of linearity. The linear dynamics exponentially speeds up information processing. И там такого в статье много. Например, "комплексная шумная динамика непрерывного пространства состояний" эффективно кодируется "символоподобным", то есть квантованным состоянием. С этой квантовостью нужно разбираться быстро-быстро. У меня ещё такая интуиция, что это правильная дорога к типизации -- та самая "символоподобность" ведь как раз про типы/различения.
После фестиваля пишу про танцы, "мышление письмом" про мемом (принципы и идеи, их надо искать где-нибудь в конструкторском/дизайнерском бюро, но вот в социальных танцах это чуть сложней) и феном (внешняя "картинка" экземпляра танца, мемом задаёт в совокупности с какими-то случайностями из окружения и случайными мутациями развитие из мемома бесконечного разнообразия чуть отличающихся друг от друга феномов). Дальше можно работать с танцами (например, учить танцам) на уровне мемома (заниматься обучением стилистике как принципам и заставлять разворачивать экземпляры исполнения из принципов), или давать сразу учить образец фенома, конечный вариант (связку, "хорягу" -- так работает хореограф), я сразу называю это по примеру биологии "мичуринством". То есть работа со стилистикой на уровне принципа -- меметическая/стилистическая инженерия, а работа на уровне экземпляра конкурсного или концертного исполнения "по образцу" или "по канону" -- мичуринство. И дальше идеи про каноны танцевальных стилей как технические стандарты: эволюционная конкуренция двухуровневая -- мичуринская по реализации стандартов и эволюционная по предложению новых стандартов. Все эти тексты я потихоньку разворачиваю в традиционном месте -- сообществе системного мультиданса, смотрите там посты последней недели, https://vk.com/buffdance. Но я ещё про стилистику и ритмику планирую большой пост написать, progress report по исследованиям последней пары недель.
Появилось много моих фоток с морского Q-fest. Можете полюбоваться, как я выглядел на море тут, это первые 40 фоток по ссылке https://vk.com/albums2449939. Вот одна из этих фоток, момент танца на конкурсе:
