?

Log in

No account? Create an account
Лабораторный журнал
 
[Most Recent Entries] [Calendar View] [Friends]

Below are the 20 most recent journal entries recorded in Anatoly Levenchuk's LiveJournal:

[ << Previous 20 ]
Saturday, September 14th, 2019
11:34 pm
lytdybr
7 сентября 2002 года произошла серьёзная перестройка в моём экзокортексе: я начал писать "Лабораторный журнал" (laboratory log) в тогда ещё относительно новом стиле web log, или сокращённо blog в ЖЖ. Тем самым моя осознанность повысилась (про киборгизацию и осознанность только что я писал тут: https://ailev.livejournal.com/1488271.html). То, что мелькало в моём мозгу, я записывал (это ведь и предполагает лабораторный журнал! дневник, дневник!). А потом появился Яндекс, помогавший искать по моим записям. Потом Яндексу в этом плане поплохело, но наладилась работа с Гуглём (для поиска в моём блоге нужно добавлять в строчку поиска site:ailev.livejournal.com, у меня это делается клавиатурной макрой в Punto switcher). И теперь я спокойно думаю одну мысль десяток лет, довольно быстро восстанавливая контекст того, что занимало мозг раньше -- сам я не гений в удержании внимания на таких длинных временнЫх интервалах, но с ЖЖ и Гуглём это как-то получается. При этом часто находятся таки мысли, за которые потом стыдно. Вот, например, мои тезисы доклада "Реформирование инфраструктурных сетей в «естественных монополиях»" на Байкальском экономическом форуме 18 сентября 2002г. -- https://ailev.livejournal.com/8014.html. Это 17 лет назад. "Когда мы были молодыми и чушь ужасную несли". Путин к тому моменту правил только пару лет. И тогда этот доклад казался вполне state-of-the-art, за него ничуть не было стыдно. А теперь тщета моих дел в те годы хорошо понятна. Ну, через семнадцать лет и многие сегодняшние мои дела будут казаться дичью. Но есть надежда, что не все.

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


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

Вот структура самого буффа, а в ней показано, чему будем учить (ориентировочно это будет интенсив 3 месяца по три раза в неделю по паре часов вечерами, а по числу учебных часов это будет похоже на "Системный менеджмент и стратегирование" -- где-то 72 часа. Скоро объявим семинар, где будем об этом рассказывать подробней):


Идут семинары выпускников по системному менеджменту (вот выложена только что запись ещё одного -- https://www.youtube.com/watch?v=tVlPXhvO5kw), а ещё у меня сейчас в работе пять менти. Со всеми одна и та же проблема: системное мышление ОК, но онтологика не-ОК, ровно по линии из https://ailev.livejournal.com/1465753.html. Похоже, нужно просто сержантским методом потратить больше часов, чтобы люди научились отличать отношения часть-целое, классификации, специализации, а также физические объекты и их описания. Чтобы цепочки обеспечения надёжно удерживали в обсуждении цепочками, а не путались с постоянным перещёлкиванием внимания. Чтобы удерживались в рамках одного view (например, функциональное описание, не сваливаясь в конструктивное описание), а view не путали с системными уровнями. С одной стороны, семинары и менторство решают именно эту проблему -- налёт часов с обратной связью от препода, в том числе и обратной связью в области онтологики. Но очень хочется больше времени тратить на прикладные обсуждения, а не на базовые навыки онтологики. Нужно как-то уже эту проблему онтологической надёжности мышления, онтологической беглости решать, что-то с этим делать. Что-то мне подсказывает, что решение будет лежать по линии языка моделирования (да, опять упираемся в SysMoLan и его моделер с возможностью exploratory modeling) и задачек на моделирование с автоматической проверкой.

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

Им объявили темы школьных сочинений этого года. Да, "Война и мир" там есть -- я писал своё школьное выпускное сочинение в 1975 году, прошло с тех пор 45 лет (писать он будет в 2020 году!), а эта дурацкая система образования продолжает играть этот день сурка, из года в год.
2:18 pm
AI таки сдаёт российский ЕГЭ в этом году!
Моё предложение провести конкурс AI по сдаче экзаменов ЕГЭ (я давал его в апреле на одном из совещаний, подробности см. в https://ailev.livejournal.com/1468166.html) таки реализовано, хотя и не UpGreat, а Сбербанком -- https://contest.ai-journey.ru/ru/competition. 4 сентября стартовали, через 43 дня совревнование закончится, вот тут рейтинг участников, https://contest.ai-journey.ru/ru/leaderboard, там всё уже более чем бодро. Всё, как я и предлагал, включая проверку сочинения по тем же правилам, что и в реальном ЕГЭ -- https://4ege.ru/russkiy/56964-kriterii-ocenivaniya-sochineniya-v-ege-2019.html. И даже перевод результатов в знаменитые "сто баллов" тоже будет как в ЕГЭ -- https://4ege.ru/novosti-ege/4023-shkala-perevoda-ballov-ege.html. Моя идея была -- проверять AI на интеллект ровно так, как проверяют людей, причём неизбежная дискуссия покажет с ещё большей очевидностью, что все эти "проверки на интеллект" не работают -- ни для людей, ни для роботов.

При этом в США такой экзамен проводится по тесту науки (мультипредметный тест), https://leaderboard.allenai.org/anli/submissions/about -- люди по нему получают 92%. Even in 2016, the best AI system achieved merely 59.3% on an 8th Grade science exam challenge. This paper reports unprecedented success on the Grade 8 New York Regents Science Exam, where for the first time a system scores more than 90% on the exam's non-diagram, multiple choice (NDMC) questions. In addition, our Aristo system, building upon the success of recent language models, exceeded 83% on the corresponding Grade 12 Science Exam NDMC questions. The results, on unseen test questions, are robust across different test years and different variations of this kind of test. They demonstrate that modern NLP methods can result in mastery on this task. While not a full solution to general question-answering (the questions are multiple choice, and the domain is restricted to 8th Grade science), it represents a significant milestone for the field. Это всё те самые языковые модели, подхаканный BERT (RoBerta в данном случае, подробности решения https://arxiv.org/abs/1909.01958), картинка с результатом для теста 8 класса:


Современные языковые модели, конечно, содержат не только модели именно языка. Они содержат и модели мира, конечно: отражают не только то, как описывают мир текстами, но и существенные черты самого мира -- что описывается текстами.

Дальнейший прогресс, конечно, будет по линии гибридных вычислений: knowledge graphs aka семантические сети aka символический искусственный интеллект в сочетании с нейронными сетями. Вот небольшой обзорчик knowledge graphs на конференции Association for Computational Linguistics ACL2019 (30 докладов из 660 -- почти 5%, это немало): https://medium.com/@mgalkin/knowledge-graphs-in-natural-language-processing-acl-2019-7a14eb20fce8. Но уже после этого обзора появились интересные работы, типа https://arxiv.org/abs/1908.07141, LogicENN: A Neural Based Knowledge Graphs Embedding Model with Logical Rules. We prove that LogicENN can learn every ground truth of encoded rules in a knowledge graph. To the best of our knowledge, this has not been proved so far for the neural based family of embedding models. Moreover, we derive formulae for the inclusion of various rules, including (anti-)symmetric, inverse, irreflexive and transitive, implication, composition, equivalence and negation. Our formulation allows to avoid grounding for implication and equivalence relations. Our experiments show that LogicENN outperforms the state-of-the-art models in link prediction.

Link prediction -- это create or recover missing links in knowledge graphs, e.g., identifying the birthplace of a person or the CEO of a company. Проблема тут не только в точности предсказания (и глубокие модели тут, конечно, побеждают всякие одноуровневые алгоритмы), но и в огромных вычислениях. Так что в эту точку бьют и работы, позволяющие меньше вычислять, типа https://exascale.info/assets/pdf/ostapuk2019www.pdf. Этих работ множество. Помним, что один из лидеров в knowledge graphs классического вида CYC делает ставку тоже на нейронные сети и вероятностные методы для эвристических способов ускорять логические вычисления в своих огромных графовых базах знаний -- Doug Lenat, например, хвастается тем, что от по факту финансирования госсиловиками перешёл в последнее время к нормальному финансированию коммерческими компаниями и теперь CYC прибыльная компания -- https://www.forbes.com/sites/cognitiveworld/2019/07/03/what-ai-can-learn-from-romeo--juliet/, https://www.cyc.com/publications/ (при этом они не стали более открытыми, всё так же мало кто понимает, что там происходит. Но точно происходит много интересного. Другое дело, что теперь они абсолютно не одиноки. Их стремительно догоняют по всем фронтам).

Тема Ontology Summit 2020 -- как раз knowledge graphs, http://ontologforum.org/index.php/OntologySummit2020. Слайды и видео первой встречи "Why Knowledge Graphs Hit the Hype Cycle and What they have in common" см. http://ontologforum.org/index.php/ConferenceCall_2019_09_04.

Так что наступает очередная весна не только нейронных сетей, но и семантических сетей (минус слово "семантические", ибо semantic web и OWL существенно дискредитировал идею, и идёт возврат к истокам).

А дальше, как всегда: дикие дискуссии о том, что школа учит не жизни, а сдаче ЕГЭ. Школьники на выпуске будут не уметь жить и работать, а уметь сдавать ЕГЭ, в совершенстве! И AI будут уметь не жить и работать, а сдавать ЕГЭ в совершенстве! Самые разные ЕГЭ самых разных стран. Например, сдадут экзамен на доктора (почему бы и нет!) и захотят работать врачом. Другое дело, что работать врачом -- это не сдавать экзамен, на экзамен-то можно натаскать, а на работу что-то другое требуется.

Я вот даже в своей семье не могу объяснить, что учиться нужно работать, а не сдавать экзамен. Мне говорят "потерпи год, и всё кончится". Я-то потерплю, а бесполезно проведённый год жизни вьюноша куда девать? Ему, бородатому, работать уже нужно, или хотя бы учиться работать. А он учится сдавать ЕГЭ, и я единственный, кто против.

Ровно та же история с экзаменами по профстандартам в качестве допуска к профессии. Тестируется одно, а на работе требуется абсолютно другое!

Очень надеюсь, что успешно сдающий экзамены ЕГЭ, экзамены на профстандарты AI как-то внесёт свежую струю в эти обсуждения.
Thursday, September 12th, 2019
1:42 pm
Роли начальников, роли помощников, роли любителей, роли карьеристов
Начальник в проектных ролях -- это джокер, играет любую подвернувшуюся ему роль. Имеет право. Квалификация игры по роли тут уже не имеет значения -- "я начальник, ты дурак", если спецы по данной роли в команде есть. При этом у начальника хотя бы есть полномочие делегировать исполнение роли, если есть кому. А вот у самых разных помощников/ассистентов по должности делегировать исполнение роли обычно некому, хотя "должностные обязанности" примерно так же расплывчаты, как у начальников -- "заниматься всем, чем нужно". И об уровне образования помощников пекутся много меньше, чем об уровне образования начальников. При этом на помощников накидывают не только много работы (это нормально!), но много работы по самым разным практикам -- а это означает, что квалификация помощников в выполнении этих разных практик будет плохой, они не смогут специализироваться и достигнуть мастерства по каждой из них.

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

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

Пример из моего любимого детского садика Монтессори (https://ailev.livejournal.com/1485977.html): помощник педагога там имел целый букет страннейших ролей, в том числе роль охранника. Помощник педагога в роли охранника отгонял по вечерам детей от дверей, ибо дети садились под двери и ожидали там родителей. Роль охранника поменяли на роль аниматора: помощник педагога играл с детьми, и ни у кого из детей не появлялось желания выйти из игры и сесть под дверь. Этот пример показывает, что разбирательство с ролями ведёт часто к архитектурным решениям: важнейшие/архитектурные решения для организации это про то как роли распределяются по их исполнителям. Так вот иногда интересней поменять не исполнителя, а саму роль и играемую этой ролью практику. Заметить такую ситуацию и даёт работа с таблицей ролей.

Таблица ролей даёт и много материала для лидерской работы (как живых людей уболтать выполнять их роли): часто люди начинают играть те роли, которые никак не соответствуют занимаемой ими должности -- это любительские роли. Почему это происходит? Иногда причина в кривизне архитектуры: делать дело/выполнять ролевую практику нужно для успеха проекта, но конструкция/штатное расписание не предусматривает для этого дела ровным счётом ничего. И это обычная ситуация, тут ничего не поделаешь. Но иногда причина в личных ролевых предпочтениях, людям нравятся какие-то роли, хотя работа от них этого не требует (а иногда выполнение таких ролей и прямо вредит работе). Я когда-то играл в духовом оркестре военной кафедры, и любил сыграть там на концерте на саксофоне какую-нибудь джазуху: хриплый тембр саксофона при этом легко перекрывал весь остальной оркестр и мою импровизацию легко было слышать из зала. Ни в каких нотах этого не было, для выступления это было не нужно, это были мои персональные хотелки. Иногда для успеха концерта это было хорошо, иногда плохо. В любом случае -- это была проблема лидерства: я в самый критический момент (на концерте) от проектной роли игрока маршей по нотам лихо отходил, и играл любительскую роль джазмена, уж как мог. Лидер оркестра регулярно с этим разбирался, это была его проблема. Если в игротехнической компании человек в должности менеджера проекта играет роль игрока-любителя, то вместо управления проектом/операционного управления он будет тратить много рабочего времени на обсуждение вопросов геймдизайна.

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

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

Табличка с ролями поднимает осознанность в организационной работе (https://ailev.livejournal.com/1488271.html), служит чеклистом: она заставляет думать про какого-нибудь программиста как программиста-должность, программиста-роль, программиста-исполнителя и не позволяет ничего из этого пропустить. Дальше можно задаваться вопросом про квалификацию исполнителя роли, про достаточность полномочий должности для игры по роли, уместность этой роли у данной должности и т.д. В случае программиста ответы на эти вопросы будут тривиальны, но не всегда (интересы любительства или карьерные интересы могут вас сильно удивить в некоторых случаях). А вот в случае должностей начальников и помощников мой опыт свидетельствует, что удивление результатами рассмотрения по табличке наступает почти всегда: должности настолько заслоняют их роли в обыденной жизни, что работа с их ролями обычно открывает что-то новенькое и даёт много пищи для размышлений и улучшений.
1:58 am
SysMoLan как eDSL для Julia
В дискуссии о типах языков программирования/моделирования/представления знаний (там, кстати, уже 320 дискутантов -- https://t.me/typeslife) сегодня был очередной поворот: попытка вместо говорения об онтологии и представлении знаний (что сразу вызывает математических и философских духов) говорить о предметно-специфичности, продолжая программистскую традицию и попадая в программистский язык. Так что ответы на наши вопросы про языки моделирования разных предметных областей будем искать по ключевым словам "domain-specific".

Когда-то и Fortran называли domain-specific, ибо он только для formula translations, а не универсальный, как машинный язык. И то же самое было со всеми языками высокого уровня, они были domain-specific. Тем не менее, domain-specific пока чётче ведёт к цели, чеми использование всяких других слов. Нам нужно делать еmbedded domain-specific languages (eDSL) с domain-specific types (как онтикой предметной области) и domain-specific solvers (для того, чтобы интерпретировать модели в онтике/типах предметной области, задавать вопросы/делать запросы/вычислять).

В группе "Аттик" мехмата МГУ рассказывали, что нашли причину, почему Паскаль никак не мог победить Фортран в своё время. Они считали, что Паскаль был безблагодатен по сравнению с пакетными языками (Modula, Ada), ибо не было "пакетов" как раз для реализации общей для нескольких программистов системы типов — нельзя было делать "пакеты" как eDSL для domain-specific работы (те самые domain-specific types и domain-specific solvers, в терминах группы Аттик domains -- это были миры и solvers -- исполнители для этих миров). В Фортране же это реализовалось на раз-два через common-блоки! Потом какие-то аналоги common blocks начали делать в паскаль-компиляторах (но это уже потом! в учебниках паскаля это не было свойством языка, а только свойством реализации в конкретном компиляторе). Потом появились на краткий исторический миг пакетные языки, а потом domain specificity начали понятными словами объяснять как делать в ООП и в реляционных моделях данных — тут все эти "пакетные языки" и деревянные с сетевыми базы данных начала восьмидесятых и смыло в унитаз истории, где они и находятся до сих пор.

Вся дискуссия в чате крутилась вокруг того, что удобных для программирования eDSL языков программирования/моделирования/запросов к базам данных/представления знаний нет. Так что я продолжаю придерживаться мнения, которое выработалось у меня на прошлом такте дискусии (https://ailev.livejournal.com/1487293.html): работать тогда будем с Julia как хост-языком. И на Julia будем реализовывать структуры данных и солверы SysMoLan как eDSL.

Вчера на докладе на митапе по Julia (https://juliameetup.timepad.ru/event/1047482/, слайды https://yadi.sk/i/yBeUJJj1iuiJXQ) я высказал ещё пару идей. Солверы для eDSL отличаются тем, что эффективно обрабатывают частные случаи -- предоставляют оптимизированные для этих частных случаев решения. И в Julia как раз отрабатывается такой подход на примерах методов оптимизации (JuMP) и методов решения систем дифференциальных уравнений (DifferentialEquations). Солверы этих систем -- это просто коллекция самых разных солверов, эффективных для самых разных ситуаций. Итого eDSL выглядит как набор типов, в терминах которых удобно описывать предметную область, плюс набор эффективных солверов -- типы должны универсально отражать задачи предметной области, а солвер должен устойчиво работать и жужжать в части скорости. Поэтому типы должны быть более-менее богаты в части их конструирования для отражения объектов и отношений в domain (сравнимы в этом плане с богатыми типами статических языков программирования), но динамическими, чтобы по ходу дела в runtime подбирать оптимизацию для solver. Ну, и проблема двух языков: на одном и том же языке и компактно и красиво (с рафинадом) высокоуровнево выражать domain, но не теряя низкоуровневости в скорости. И настолько не теряя низкоуровневости, чтобы эта оптимизация докатывалась аж до уровня железа -- до GPU. Вот Julia как раз имеет примеры таких решений. Вот этим путём и хочется пойти для SysMoLan: иметь возможность самых разных солверов для предлагаемых SysMoLan как eDSL структур данных.

Идти туда, как мне кажется, нужно в несколько шагов:

1. Сделать простой (архитектурный и требований) текстовый моделер для простых архитектур и использовать его, например, для обучения инженерии требований и инженерии системной архитектуры. У меня проходит в год сотня студентов и курсантов по разным линиям, вот это будет учебный софт. SysMoLan в объёме реализации IEC81346-1 для моделирования системного разбиения (чтобы можно было показать функциональное и конструктивное системное разбиение в их взаимосвязи на пару уровней) тут вполне подойдёт. Это MVP. Ничего вычислять даже не будем (может быть, будем проверять целостность, но и тут не факт), только отображать удобно. Солвер -- голова инженера. Для чего такое нужно? Для помощи со стороны компьютера в присмотре за вниманием в ходе архитектурной работы и работы над требованиями, речь идёт о киборгизация архитектора (вот тут про киборгизацию присмотра за вниманием: https://ailev.livejournal.com/1488271.html). Как над шахматными партиями удобней думать, если есть просто шахматная доска, на которую можно смотреть, так и архитектурный моделер помогает думать уже тем, что он помогает стабилизировать внимание архитектора.

2. Иметь полноценный текстовый язык представления знаний в качестве полноценного системного языка. Тут уж точно иметь eDSL, ибо к более-менее сложным архитектурным моделям и моделям требований захочется делать запросы.

В чате была дискуссия о том, что лучшим приближением к языкам представления знаний является common logic, и какой-нибудь FOL солвер. При этом SQL предлагался как успешный вариант языка для FOL -- без пояснения того, как это всё предполагается в работе у инженера. Ибо логические языки почему-то нигде не взлетели в их чистом логическом виде.

Тут ещё и социальные аспекты, конечно. Пара релевантных ссылок в Communications of ACM (http://cacm.acm.org/blogs/blog-cacm/173328-programming-languages-are-the-most-powerful-and-least-usable-and-learnable-user-interfaces/fulltext) -- там обсуждается вопрос, почему люди не хотят учить языки программирования (языки моделирования, языки мета-моделирования). Там вводят понятия cognitive load (http://en.wikipedia.org/wiki/Cognitive_load, связанные с использованием рабочей памяти умственные усилия), для разных людей они будут разные при изучении предмета. И далее говорится, что люди оценивают не реальную когнитивную нагрузку, а субъективно воспринимаемую (percieved) будущую нагрузку -- когда вы даже воспринимать её по факту не можете, ибо ещё не знакомы с предметом. Да, и полезность вы тоже представить не можете, ибо не знакомы с предметом. А решение "учить-не учить" принимается до изучения предмета. То есть бесполезно уговаривать что-то учить, потому как оно "полезно". Решение принимается не только и не столько по "пользе", сколько по "цене изучения" -- например, считает ли потенциальный ученик, что у него есть способности к предмету. Это всё expectancy value motivational theory -- https://www.researchgate.net/publication/265965932_Expectancy-Value-Cost_Model_of_Motivation. If students are not convinced they can learn it and they are not convinced of the value, then they don't learn it. Решение автор текста предлагает в повышении usability для изучаемых предметов (языков программирования/моделирования), но и learnability -- это разные свойства. Requirements нужно формулировать для обеих характеристик. Легко такую банальность предложить, трудно выполнить.

Вопрос мой в том, что современные информационные системы решают многие из тех задач, которые раньше считалось, что смогут решать только экспертные системы. И эти системы написаны на обычных языках программирования, а не на логических языках. Нет ли какого-то способа представления знаний, отличного от тупого использования логического языка? Логическая парадигма только одна из многих, и в языках программирования она явно не главная. Иначе мы бы видели вокруг сплошных потомков Пролога. Но нет, потомки Пролога везде маргинализуются, и никакая опенсорсовость им не помогает. CycL тоже делал OpenCyc, потом закрыл этот проект: не взлетело. Логическое не взлетает, на SQL делают только запросы в базу данных, а не программируют -- вот я и интересуюсь, что ещё на свете существует для представления знаний. Какая-нибудь Java для представлений знаний неудобна, но модели самых разных domain обрабатываются в мире главным образом на ней, а не на CycL или Agda. Получается, вся краса мира у нас уходит в язык программирования, который нужен для того, чтобы вызвать SQL над базой данных, в которых и отображён domain. При этом как domain отражается в реляционных базах данных — понятно, этому учат в университетах, и по большому счёту DDD (domain-driven design) тоже редко когда про язык программирования, чаще про базы данных.Ответа в чате я так и не получил, хотя обсуждение и было бурным. Так что за подробностями отправим в чат, а тут продолжим.

3. Иметь дифференцируемый язык представления знаний как eDSL, чтобы использовать этот язык не только для ручного ввода архитектурных моделей и моделей требований в рамках облегчения работы subject expert по knowledge aquisition, но и в рамках порождения/generation, а ещё в рамках оптимизации (про "дифференцируемое всё" я писал в https://ailev.livejournal.com/1464563.html). У Julia тут неплохая репутация: Viral Shah [один из разработчиков компилятора Julia] addressed the World Artificial Intelligence Conference, held in Shanghai Aug 29-31 with a discussion on "Julia: Generalizing Deep Learning with Differentiable Programming" (почему я и хотел бы держаться к Julia поближе, а не к C#, С++, R или каким-то другим языкам, не приспособленным для численных методов). Порождаемые архитектуры, оптимизируемые архитектуры, фронтир — вот это всё тут, все эксперименты с искусственным интеллектом и компьютерным творчеством.

4. А ещё нужно будет реализовать mapper (генератор конверторов/адаптеров/плагинов/мостов и т.д. -- систему типа .15926 https://github.com/TechInvestLab/dot15926/, только не обязательно на ISO15926, зато с удобным порождением парсеров и генераторов данных, eDSL для этого), ибо любой архитектурный редактор быстро будет нуждаться в частных моделях из разных САПР, и дело быстро дойдёт до полноценной PLM. Когда будет реализовываться мэппер, там результат будет вполне дискретный и формальный и FOL внутри, а вот методы получения моделей данных могут быть с использованием нейросетей, вероятностных языков и разных других численных алгоритмов. В итоге получится гибрид, а не только нейросети или только строгая логика. Вот, кстати, пример такого "загрузчика данных" (мэппера) для табличек: о "импорту табличек в программу", Flatfile can automatically match 95% of imported columns, using a combination of machine learning and fuzzy matching. Users can upload data via CSV, XLS, or simply paste from the clipboard — https://venturebeat.com/2019/09/10/flatfile-pursues-intelligent-data-importing-with-2-million-round/. JuliaDB при этом тоже работает с файлами табличек, в колонках которых могут быть любые типы Julia, а не только числа или строки, но всё-таки мэппер должен работать не только с табличными форматами. Первое, о чём спросят инженеры, так это о мэппинге 3D-моделей современных САПР.

Задача представления системных знаний на SysMoLan сложная, поэтому решаем её эволюционным путём, а не "сразу всё во взаимоувязке". Системный подход не должен становиться болезнью, когда вгоняет проект в analysis paralysis и заставляет "учесть всё-всё" в один подход и один проход.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216230511529525
Wednesday, September 11th, 2019
6:36 pm
Киборгизация людей и организаций: поднимаем осознанность, то есть рулим вниманием
Киборгизация идёт как для людей, так и для организаций:
-- cyborg = cybernetic organism -- оригинальное определение киборга как одного организма,
-- cyborg = cybernetic organization -- организация тоже киборг, и суть киборгизации остаётся та же: добавляем компьютеры, датчики, эффекторы.

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

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

Тезис этого текста в в том, что киборгизация позволяет поднимать осознанность как личную, так и корпоративную. Записная книжка заменяет 10 лет ежедневной тренировки памяти человеку, а issue tracker заменяет 10 лет усилий налаживания сотрудничества для организации. Киборгизация сильней психопрактик, кофе сильней психопрактик. У нас технологическая, а не психотехническая цивилизация. Психотехники должны помогать прилаживаться к технологиям, цивилизационно сегодня они не самодостаточны, они были самодостаточны 2000 лет назад, но за время пути цивилизация смогла подрасти.

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

Системная киберосознанность прежде всего -- это работа с (shared, к одним и тем же предметам, "синхронизированным") вниманием на отчуждённых от людей и тоже shared системных описаниях, работа с глубокими стеками абстракции этих описаний, удержание внимания на тех или иных ролевых описаниях (viewpoints). Отчуждённие от людей, задействование (личного и корпоративного) экзокортекса позволяет:
-- удерживать внимание в ходе личного и коллективного мышления на большем числе объектов (они не исчезают при неминуемых сбоях внимания личности и провале внимания коллектива): мышление с экзокортексом легко обрабатывать реально большие схемы и делает при этом мало ошибок
-- асинхронно мыслить в коллективе: подумал сам, передал товарищу. Никто никого не ждёт, не нужно находиться в очном диалоге и лично присутствовать или даже присутствовать онлайн. Даже диалоги по телефону уходит в асинхронность: замещаются чатами. И совещания (полилоги -- очные или по селектору) всевозрастающе заменяются чатами.
-- обсуждать с другими или компьютером на предмет обнаружения ошибок (экспликация и коммуникация объектов внимания) – и маленькие, и большие схемы. Сшивка больших схем вместе («интеграция»).
-- Делать перерывы для отдыха и отвлечений (не теряются результаты промежуточных рассуждений), выдерживать долгие размышления без «закрытия», в том числе «многопроходные» размышления, в том числе в масштабах организации.
-- Освобождать головы в организации для дополнительных рассуждений (например, «мета» о способах мышления, сторонние исследования и т.д. – более сложные траектории мышления), не теряя контекста и результатов предыдущих шагов размышления.

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

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

Организационная осознанность -- это надзор/присмотр за вниманием по shared схемам организации. То есть речь идёт о том, что находится в информационных системах организации. Конечно, в организации есть и часть shared tacit knowledge. Но легче работать с explicit knowledge в организационном экзокортексе, в информационных системах. Это полностью соответствует attention schema theory по вопросу того, как устроено сознание: в информационной системе компании находится упрощённая схема, организующая внимание. Так что путь развития организационной осознанности -- это развитие информационных систем компании прежде всего, улучшение её информационных моделей, а не попытки заставить людей удерживать системное целое на много-много уровней выше тех систем, с которыми работают отдельные люди в организации. Весь этот присмотр за вниманием многих тысяч людей, распределённым по многим и многим системным уровням объектов организации и её окружения, обеспечивают по сути не менеджеры, не сами люди, а информационные системы. Так что для поднятия организационной системной (для многих системных уровней) осознанности киборгизация идёт в два такта:
-- просто управлять данными, data management -- это делать данные/схемы доступными тем, кому надо и когда надо. Никакой обработки данных, чистая логистика. Записал, сохранил, проверил версию, воспроизвёл актуальное. Базы данных сами по себе благо, они удерживают внимание организации и организуют её память. Главный инструмент -- это моделер, редактор. Ничего страшного, если корпоративная информационная система ничего не считает, а просто хранилище структурированных и даже неструктурированных данных. Она крайне полезна! Она помогает присматривать за вниманием, бороться со сложностью самой организации и окружающего организацию мира.
-- и только вторым пунктом в киборгизации/информатизации тут творчество, принятие решений, искусственный интеллект или машинное обучение и т.д..

CAD, который только "моделер", сиречь "редактор", и который ничего не автоматизирует (по-английски сomputer-aided design, но по-русски это САПР, система автоматизированного проектирования) уже приносит пользу: помогает управлять вниманием, реализует экзокортекс проектировщика -- одного человека (проектирование-в-малом) или нескольких проектировщиков (проектирование-в-большом, https://ailev.livejournal.com/851977.html -- в том числе выход в системы систем). Сначала учётная система и управление изменениями, поддержание актуальной (хотя и заведомо упрощённой -- схема!) модели реальной жизни в личных корпоративных информационных системах. Потом "автоматизация".

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

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

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

Литература (все непонятные слова из текста разъясняются в литературе, а не в самом тексте. Как читают научные статьи? Читают статью, и если что непонятно, то читают первоисточники. Если что непонятно в первоисточниках, то читают литературу к этим первоисточникам. И так дальше, пока не будет понятно всё. Для первого знакомства с предметной областью текста это может занять некоторое время. Если литература/первоисточники уже читаны, то тогда и сам текст должен быть понятен):
-- интернет вещей. Интернет клеток. Интернет программы -- https://ailev.livejournal.com/810255.html (киборгизация приходит оттуда, откуда её не ждут: на системных уровнях выше человека, на системных уровнях ниже человека).
-- Теория сознания как схемы внимания -- attention schema theory -- https://ailev.livejournal.com/1193568.html (и там в том числе про важность темы внимания для representation learning/deep learning). По сути, мы говорим в данном тексте о внимании в организации.
-- Тема психопрактик движения по спектру формальности -- https://ailev.livejournal.com/1461939.html
-- киберосознанность must, киберпсихика rulez -- https://openmeta.livejournal.com/237056.html
-- когда целевая система -- (кибер)люди -- https://ailev.livejournal.com/1459254.html
-- Системная осознанность, 2019 -- https://ailev.livejournal.com/1487672.html
-- Птолемеевская модель человека -- https://ailev.livejournal.com/1390574.html
-- Оргроли нескольких организованных (с известными полномочиями по распоряжению трудом и ресурсами) оргзвеньев и оргзвенья из нескольких оргзвеньев: https://ailev.livejournal.com/1487927.html (унификация рассмотрения людей и их организаций)
-- кофейный нейронет: https://www.facebook.com/groups/nevronet/permalink/1061187754047545/ (употребление кофе до выполнения задачи улучшало оценки работоспособности коллектива в 1,4 раза по сравнению с контрольной группой).
-- Мойдодыр и политическая философия интернет-вещизма, https://ailev.livejournal.com/1106188.html (кому принадлежат программные системы, которые могут влиять на нашу жизнь? Нам? Корпорациям? Госчиновникам?)
-- ссылки на несколько работ о путях эволюции цивилизации, в которой алгоритмы управляют вниманием людей: https://www.facebook.com/groups/nevronet/permalink/1314884872011164/.

UPDATE: Обсуждение в фейсбуке -- https://www.facebook.com/groups/blended.learning.russia/permalink/2415362628706272/
12:00 pm
Роли деятельностные, проектные, функциональные, организационные
Проектные роли, деятельностные роли, функциональные роли, оргроли — это всё одно и то же, только акценты их рассмотрения немного (но только немного) разные. Если хотим рассматривать в отрыве от конкретного проекта (например, вопросы подготовки специалистов, которые будут играть эти роли в самых разных проектах), это деятельностные роли и культурная обусловленность тут вообще в центре. Когда речь идёт о проекте, то проектная роль и связка с исполнителем. Когда об организации (и необязательно даже один человек) и её архитектуре — то функциональная роль или оргроль. При этом ещё и должность/полномочия исполнителя важны (роль по факту получает ресурсы через полномочия, которые даёт должность). Главное — это понимать, что с собственно ролью связана практика (что делает человек, каково назначение его деятельности), какие у этой роли интересы и т.д..

Хитрость в том, бывает ли "уникальная роль для одного человека". То есть можно ли считать, что свежевыдуманная деятельность (оператор только что придуманного компьютера ENIAC, пилот первого в мире самолёта) является культурно-обусловленной? Мне кажется, что тут уже идут нюансы. Роль вебмастера и практика вебмастеринга просуществовали вообще несколько лет: была ли она культурно-обусловлена, были ли там интересы и предпочтения этой роли? Можно ли считать, что верстальщик, редактор, контент-менеджер, программист веб-движка и т.д. вместе это подроли верстальщика так же как гинеколог и дантист это подроли врача? Не бывает же "вообще врача"!

Этот вопрос примерно тот же, что вопрос про определение онтологии: по Груберу это спецификация концептуализации, но не любая, а shared/разделяемая. То есть относящаяся к культуре, "народная", а не лично прямо сейчас придуманная. Но кто-то ведь концепт или целую группу концептов (микротеорию, онтику) обычно придумывает, а потом уже это либо становится популярным (и можно говорить "онтология"), либо непопулярным (и тогда говорить "онтология" нельзя). В DDD (domain-driven design, сегодняшняя форма бытования онтологической инженерии) поначалу требовалось в программных объектах специфицировать как раз эту folk ontology предметной области, но в последнее время всё больше голосов раздаётся в пользу какой-то рационализации, компактификации, переформулирования этой онтологии: перехода от специфицирования as is к разработке более удачных онтологических представлений о domain, и уже только после этого реализации в программных объектах. В работе с человеческими деятельностными, проектными, функциональными, организационными ролями, которые занимаются практиками для своих domain, вся эта дискуссия присутствует в полной мере.

Этот пост появился из обсуждения в чате поддержки курса системного мышления, старт был с реплики https://t.me/systemsthinking_course/7469, где рассказалось о том, что замминистра на конференции пил кофе из керамической чашечки, а через год он был уже не замминистра и на той же конференции пил кофе из пластикового стаканчика. Замминистра -- это роль? Полезный для организаторов конференции человек -- это роль? Если речь идёт о совсем новой роли, уникальной для одного проекта -- это роль?

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

С людьми всё сложно, увы. Полномочия по распоряжению ресурсами, привилегии -- это должности и статусы, что содержательно делает -- это роли, кто занимает должность и играет роль -- это исполнитель. А ещё всё это рассуждение можно проводить про какую-то группу ролей и/или группу людей. И при проектировании системы из людей разговор ведётся в классах (та самая обобщённость, культурная обусловленность, знакомость присутствующим, возможность переноса рассуждения из одной проектной ситуации в другую) -- что трудно делать, если речь идёт о конкретном человеке в уникальной (пока ещё) и поэтому противоречиво понимаемой роли.
Sunday, September 8th, 2019
2:04 am
Системная осознанность, 2019
Осознанность -- это одно из архитектурных требований к мышлению (остальные -- адекватность, абстрактность, рациональность, это было в http://ailev.livejournal.com/1342372.html):
Осознанность – это возможность понять, как мы мыслим, как мы рассуждаем. Если мы просто «имеем интуицию», это нас не удовлетворит. Мы не сможем научить других мыслить, научить их повторять наши рассуждения. Мы не сможем заметить ошибку в нашем мышлении, не сможем его улучшить или изменить, не сможем выучить другой способ мыслить, ибо мы его не будем замечать, не будем его осознавать. Мы не сможем удерживать внимание в мышлении, ибо нельзя удерживать внимание на том, чего не осознаёшь. Мы не сможем предъявить неосознаваемое нами мышление для проверки со стороны логики и рациональности, не сможем сознательно принять решение о том, что в той или иной ситуации нам достаточно от мышления интуитивной догадки, а не строгого рационального рассуждения. Мы хотим знать, о чём мы размышляем, как мы это делаем, мы хотим иметь возможность выбирать – мыслить нам о чём-то или не мыслить, мы не хотим быть бессознательными мыслящими автоматами. Мы хотим быть осознанными в мышлении, мы должны учитывать не только мышление, но и наличие самого мыслителя". Ещё сюда: "«рефлексия» – это осознанность, но только не на текущую ситуацию, а уже прошедшую".
Системную осознанность определяем сегодня чуть точнее как действенный надзор/присмотр за вниманием в мышлении и восприятии по следующим линиям:
-- внимательность к вниманию, осознание характеристик первичного/целевого/uptime/вовне/ролевого внимания: его концентрации, стабильности, направленности). Моё первичное внимание занимает сейчас печатаемый текст, и осознанность позволяет мне это внимание к тексту отследить, замечать изменения его качества.
-- агентность/деятельностность/прагматичность/целенаправленность: постановка первичного внимания под контроль/надзор/governance в рамках осознанности. Не просто пассивное "осознавание" того объекта, на которого направлено первичное внимание, но и выбор того объекта в мышлении или окружающем мире/восприятии, на которое будет это первичное внимание направлено (удержание стабильного фокуса внимания на каком-то объекте, выбор уровня деконцентрации-концентрации). Если моё внимание уплывает от печатаемого текста и во внимании вдруг оказывается лента фейсбука, то я могу вниманием осознания это не просто отследить, но и волевым действием осознанности вернуть внимание к печатаемому тексту в целом, или ситуации печати и продумывания текста с включением этого текста в ситуацию печати и продумывания, или к отдельным элементам текста. Это не пассивное "свидетельствование", ибо мы не просто так наблюдаем за первичным/целевым вниманием, и не вечно активное "управление" как непрерывное подруливание. Нет, если "всё ОК" с целевым вниманием, то осознанность ничего не делает: она дала исходные установки для целевого внимания и таки "просто наблюдает". Если что-то не так, то осознанность вмешивается и наводит порядок: это надзор/присмотр/governance. Целевое внимание при осознанности не безнадзорно/беспризорно, за ним есть присмотр.
-- системность, традиционно понимаемая как управление привязкой внимания к определённому системному уровню. Моё внимание направлено сейчас на содержательные части печатаемого текста, или на отдельные лексемы, или даже на отдельные символы в тексте. Я при этом не просто осознаю, на что направлено первичное внимание, но и могу деятельностью осознания присмотреть, чтобы первичное/целевое внимания было на выбранном, а не случайно плавающем системном уровне, то есть волевым образом перенаправить это внимание на другой системный уровень и стабилизировать его там). Не путать с систематичностью (которую иногда понимают как стабильность осознанности, иногда как обход первичным вниманием всех требуемых объектов, иногда ещё что-нибудь -- но в систематичности не следят за отношением "часть-целое", а в системности следят).
-- трансдисциплинарность: выбор дисциплины, в соответствии с которой нужно искать объекты -- это тоже объект осознанности. Осознанность кроме первичного внимания к мышлению и восприятию как своего объекта ещё работает с ролями, интересами, предпочтениями, намерениями. Дисциплина/предмет/теория для выбора концептов, для которых будут искаться объекты в мире, выбирается трансдисциплинарно в соответствии с практикой, выполняемой проектной/деятельностной/орг ролью. Вот эта роль тоже отслеживается вниманием осознанности, и её выбор и стабильность удержания находятся под трансдисциплинарным (внешним по отношению к предметам/дисциплинам) присмотром. Целевое внимание под присмотром системной осознанности -- это целевое внимание текущей роли, переключение ролей (и набора интересов, и набора поддерживающих мышление ролевой деятельности дисциплин) отслеживается и если находятся проблемы, то осознанность помогает удержаться в роли, или выбрать новую роль и войти в новую роль.
-- абстрактность мышления: осознанность следит, чтобы объекты внимания в мире и мышлении соответствовали концептам какой-то теории/дисциплины или явно были помечены как не соответствующие никакой теории/дисциплине. Отсутствие соответствующего кругозора (некомпетентность) приводит к натуральности мышления, важные объекты будут не осознаны (внимание к ним не будет привлекаться), внимание будет привлечено случайными, а не важными объектами (совпадение важных и случайных объектов возможно, но это будет случайностью). В части абстрактности со стороны осознанности идёт присмотр и за строгостью мышления (нахождение в желаемой части спектра мышления и движение по спектру мышления).
-- обеспечение/enabling коммуникации: объекты мышления/первичного внимания могут быть названы в соответствии с дисциплиной, так что можно обсуждать с другими агентами то, что находится в коллективном (а не индивидуальном!) мышлении, а не мычать. Мышление "промеж людей", оно не индивидуально, поэтому осознанность затрагивает и ролевую коммуникацию. Осознанный человек может понять, как он действует и мыслит, а затем отмоделировать своё действие и мышление (создать онтику/модель/микродисциплину/микротеорию), затем научить этому других людей так, чтобы они могли это выполнять осознанность.
-- осознанность осознанности, она сама под присмотром/надзором: при постановке осознанности нужна мета-осознанность. Мета-осознанность управляет осознанностью по отношению к целевому/ролевому вниманию -- то есть держит во внимании сам факт осознанности и направляет/нацеливает/намеревает/стабилизирует/фокусирует её. Другое дело, что эту цепочку мы не длим бесконечно, мета-мета-осознанность мы уже не обсуждаем. И осознанность и мета-осознанность мы не называем рефлексией (рефлексия это по отношению к уже прошедшему, а осознанность и мета-осознанность в "здесь и сейчас", одновременны с целевым вниманием).
-- произвольность включения/выключения: желателен режим, когда внимание работает и переключается "на автомате", им не требуется рулить, большинство мыслительных и физических действий происходят бессознательно в силу их автоматизма. Но если потребуется, осознанность позволяет чётко дать себе отчёт, что происходит, на что направлено внимание, что сейчас думается и делается. И это можно будет коммуницировать/документировать/обсудить, причем неважно --сейчас или потом после документирования, с самим собой или другими. Важно, что можно отдавать присмотр "автомату" и забирать контроль у "автомата", входить и выходить из режима неосознанности мышления -- мы автоматически открываем ключом дверь, но если нам нужно, то мы сможем рассказать про смысл каждого движения и описать их последовательность, назвать все участвующие в этом открытии двери объекты. Просто выключаем режим "автомата" и делаем это сознательно. Но если внимание, например, осознанно приковано к размышлению над рабочим проектом, то открывание двери ключом или мытьё посуды обязано проходить мимо сознания, не должно мешать думать о проекте -- но осознанность не должна приводить к тому, что мы в бессознанке будем тыкать не тем ключом в не ту дверь полчаса перед тем, как заметим, что "что-то не так". Осознанность нужна в том числе для того, чтобы не уходить полностью из реального мира в мир размышления/downtime ("медитация", но вы ж не называете медитацией ровно то же самое, что люди делают в ходе медитации над коаном, только когда они это делают для какой-то полезной цели -- сутками напролёт решают не заведомо бесполезную задачу типа коана, а думают над какой-то важной проблемой-из-жизни). Но осознанность позволяет и не отвлекаться на отслеживание каждого внешнего шороха, если речь идёт о размышлении.
-- отсутствие прокрастинации для осознанности: осознанность всё время работает, её не лень сохранять, тренировать, удерживать. Осознанность не ленится присматривать за вниманием в мышлении и восприятии.
-- хладнокровности осознанности: она не отвлекается на эмоции, не искажается ими. Это означает, что можно управлять вниманием в мышлении и восприятии даже в условиях испытывания сильных эмоций (отрицательные игнорировать и не расстраиваться, положительные не сдерживать -- ведь они под присмотром, и крышу от них не сорвёт! Как говорил Кен Уилбер, если у тебя есть надёжный тормоз для эмоций, то можно дать им разогнаться: это безопасно. Хладнокровность осознанности вовсе не означает безэмоциональность целевого внимания к мышлению и восприятию, она сама хладнокровна, но позволяет испытывать больше тех эмоций, которые нам нравятся и меньше тех, которые не нравятся).
Все эти свойства осознанности можно и нужно тренировать. Версия текста от апреля 2018 года, там больше красочности изложения, больше упор на то, как осознанности учить, но менее структурировано в части определения линий, по которым осознанность присматривает за вниманием в мышлении и восприятии -- https://ailev.livejournal.com/1417932.html. И там всякие дисклеймеры (например, почему мы не поминаем mindfulness и прочие медитации, и стараемся не цеплять тамошнюю терминологию, типа "внимательного присутствия", а также ссылки на замечание Игоря Берха, что "слишком много контроля -- и мышление останавливается, слишком мало контроля -- мысли хаотично мечутся, проблема в узости рабочего интервала осознанности в части поддержки действенного мышления").

Можно тут ещё добавить про телесную осознанность как присмотр за вниманием в кинестетическом восприятии:
-- ощущения от двигательной/мышечной работы. По факту, весь тренинг системного фитнеса направлен на то, чтобы поставить внимание к телу под присмотр осознанности -- осознать, что ощущения от работы мышц есть, контролировать фокус внимания к этим ощущениям от локальной концентрации в проблемном мышечном объёме до объема всего тела (например, чтобы обнаружить проблемные ощущения или наоборот -- места, где никаких ощущений нет, и поэтому нет осознанности в управлении усилиями в этом проблемном месте), работа с телом становится предметом обсуждения как с собой, так и с окружающими (при этом нет перевода ощущений на словесный язык, и предлагаются специализированные приёмы для решения этой проблемы). Более подробно методику тренинга телесной осознанности в системном фитнесе см. презентацию по системному фитнесу: https://yadi.sk/i/Wo6WAqh3iOmDPA, обсуждение в чате лаборатории телесного мышления https://t.me/labolatoryTM
-- ощущения от мыслительной работы в части выведения их на уровень осознания и дальнейшей коммуникации. Методы типа focusing и thinking at the edge, TAE, где ощущения стабилизируются, превращаются в образы, для них формулируются понятия, а затем проводятся рассуждения с этими понятиями -- см. раздел "Телесная инженерия и психопрактики" в https://ailev.livejournal.com/1461939.html

DISCLAIMER: если вы не читали учебник "Системное мышление 2019", то текст вам будет непонятен. А если вы этот учебник уже прочли, то текст будет для вас любопытен. Чего только стоит определение системности в осознанности! Мы ж помним, что системное мышление -- это прежде всего про управление вниманием, про это в учебнике подробно написано. В этом смысле системное мышление явно помогает приобрести осознанность, а осознанность в свою очередь даёт возможность системно мыслить.

UPDATE: Обсуждение в фейсбуке -- https://www.facebook.com/groups/771940449578453/permalink/2191352624303888/ и https://www.facebook.com/ailevenchuk/posts/10216203649097981
Monday, September 2nd, 2019
3:09 pm
lytdybr ко дню знаний
В этом году я буду вести два курса системного мышления в вузе: в МФТИ для технологических предпринимателей и в НИУ ВШЭ для цифровых трансформаторов образования. При этом в НИУ ВШЭ буду вести не только я, но и ещё несколько преподавателей Школы. При этом студенты в МФТИ получат ещё и системную инженерию, а студенты НИУ ВШЭ получат ещё и онтологику, и системный менеджмент в обязательной программе, и системную инженерию как курс по выбору. При этом вузы -- это ни разу не эпицентр моих потенциальных подвигов на ниве образования. Вузы просто получают готовый типовой образовательный продукт. В эпицентре же у меня методологическая работа в Школе системного менеджмента. Выходом этой работы как раз являются учебные курсы, в том числе и не мои.

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

Бородатый вьюнош закончил свои две недели "городского физмат-лагеря" в МФТИ и сходил на линейку в лицей. Я его на всякий случай предупредил, как отвечать на возможные вопросы по поводу его бороды: "моё тело, а не ваше -- что хочу, то с ним и делаю". В этом году в лицее будет безумие имени ЕГЭ. Вьюнош уже участвует в этом безумии, хочет хорошо сдать -- "чтобы спокойно поступить в вуз и не попасть в армию". Ни слова о том, что эти ЕГЭ нужны хоть для чего-нибудь, кроме отмазки от армии. Вся эта логика "учиться хорошо, чтобы сдать ЕГЭ. Сдать ЕГЭ, чтобы попасть в вуз. Учиться в вузе хорошо, чтобы" выходит не на "научиться работать и попасть на работу своей мечты", она выходит на "не попасть в армию". А научиться работать и попасть на работу своей мечты -- это мимо школы, мимо вуза. Всё абсолютно цинично, никаких иллюзий про то, что делает лицей и что делает вуз.

Я сейчас перетряхиваю содержание курса "Образование для образованных" -- учитываю все наработки предыдущей пары месяцев. Курс будет уже в эту субботу -- http://system-school.ru/uptodate, 7 сентября. Текущий поток курса "Системный менеджмент и стратегирование 2019" между тем пересёк экватор (три тренинга из шести уже прошло) и объявлен набор на новый поток, стартующий 13 октября: http://system-school.ru/sms. А вот тут сегодня опубликовано расписание наших ближайших курсов на сентябрь-октябрь: https://www.facebook.com/system.school.ru/photos/a.429374823919757/1133205676869998/

В чате по типам в языках программирования продолжается дискуссия -- я писал в последние дни туда много, но никаких особых событий это не породило. Теория категорий и теория типов, они как-то лежат в основе систем типов в языках программирования, и то не всех. Есть типы и структуры данных в языках программирования. Есть моделирование данных для баз данных. Есть советы онтологов, как моделировать данные, чтобы проще было договариваться. Всё перечисленное существует отдельно, интеллектуальных мостиков меж ними практически нет. Есть нужда в системном языке моделирования. Есть нужда в том, как знакомить со всем этим в рамках курса вычислительного мышления. Как удовлетворить эту нужду -- непонятно. Я свою цель прояснял, как мог. И даже обсуждал один из конкретных вариантов решения — https://ailev.livejournal.com/1487293.html (увы, этот вариант решения в ходе обсуждения тут не слишком продвинулся). Есть альтерантивные варианты решения, justy_tylor делает компилятор для GPL, который будет ответом на мой вопрос и он тоже проясняет свою позицию, как может. Есть любители триплов, которые надеятся, что ускорители помогут вернуть трипл-сторы в обсуждение (но есть аргументы, что это не удастся даже с ускорителями, что FOL будет, но реализована не на триплах — и даже теорию вопроса тут немного цепляли, не только инженерные рассуждения были). Есть любители естественного языка, и они призывали сначала понять, что мы в формальную модель из естественного языка хотим перетащить, а что не хотим. Ответ шёл главным образом по линии "естественный язык не безопасен", но там есть и другие варианты ответа. Были сторонники просто взять F# и считать, что ответы даны в книжке — но только там проблема с programming in the small и маргинальностью F# (хотя тут я лукавлю: были не сторонники F#, а люди, указывающие на принципиальное существование хоть каких-то работ на тему выражения знаний о мире в типах языка программирования, которую я спрашиваю). В чате https://t.me/typeslife уже 229 человек -- но существенного содержательного продвижения пока нет. Удалось только выяснить, что разговоры про теорию категорий и теорию типов оказываются никак не связаны с моделированием мира.

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

Немножко продвинулся проект по моделированию социальных танцев, смотрите новые тексты в https://vk.com/buffdance. А оргсобрание по переходу в системном фитнесе и социальных танцах от главным образом методологической работы и отдельных курсов к клубной форме у нас в ШСМ будет в этот четверг. С октября планируем запустить и новые курсы и регулярные клубные мероприятия. А сам я за последний месяц успел помоделировать в части ритмики переноса веса основной шаг танго, зука и форро. Форро оказался очень забавным: крутая замесь кизомбы с сальсой. Там обнимаются так же плотно и прочувствованно, как в кизомбе, и крутятся-бегают так же быстро, как в сальсе. И как кизомба из танго, форро тянет разные фишки из самбы. А как же моя кизомба? Ну, моя кизомба и на кизомбу уже не очень похожа, я танцую "свой стиль": в целом мой урбан-киз много быстрей, чем у всех остальных на танцполе (там где соседи делают шаг, я успеваю сам и веду партнёршу на пару шагов), а вместо таррашо у меня всякий-разный вейвинг. Ревнителям самых разных канонов такой "свой стиль" явно не понравится, но я на отсутствие желающих со мной потанцевать "это" не жалуюсь. Главное, это не скучно. Совсем, совсем не упражнения в качалке, не марафонский бег! Так что я буду продолжать учиться дальше, пусть сегодня будет и день танцевальных знаний.
Wednesday, August 28th, 2019
7:52 pm
Объединяем программирование, моделирование, представление знаний
24 августа в 13:11 был создан чат "Типы в языках программирования, моделирования, представления знаний" -- https://t.me/typeslife, и за прошедших четыре дня в него набежало уже 176 любителей поговорить о типах. Ох, и много было наговорено! Текста я туда написал тоже оченьмногабукофф, даже не буду сюда эти тексты копировать. Но сформулирую некоторые выводы.

1. В основе всего должен лежать какой-то "обычный GPL". Под этим "обычным GPL" имеется ввиду современный язык, на котором можно делать eDSL. Например, C# и Julia. Языки, на которых легко программировать, хорошая инфраструктура, приемлемая надёжность кода, надёжность обеспечивается понятностью. Языки, у которых дизайн-цель безопасность (доказательства правильности программ) -- они не подходят, а если для "обычного GPL" потребуется при передаче в production обеспечить безопасность, то ничего не нужно переписывать: просто будут воткнуты дополнительные аннотации и типизация таки будет проверена (средствами языка, или внешним чекером, это неважно), а то и в рантайме поставим дополнительные тесты.

2. Языки представления знаний -- это какая-то формальная машинка для работы с микротеориями. Обычно там какой-то логический движок, FOL плюс какие-то HOL расширения. SQL, SPARQL (забыть: триплы это тупик. Начинать нужно сразу с n-арных предикатов), Datalog и прочая -- вот это оно всё. Но смотреть нужно на CycL как на успешный движок. Другое дело, что языки представления знаний крайне не приспособлены для моделирования. Поэтому хорошо бы реализовать язык представления знаний как eDSL над GPL. И помнить, что язык для знаний -- это полноценный движок/солвер FOL прежде всего. Онтологика это онтология+логика.

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

Этот язык justy_tylor реализует как компилятор на C# (ему важна совместимость с корпоративной инфраструктурой и сахарность синтаксиса), а для меня важны были бы стыки с deep learning, probabilistic programming и NLU + всякое инженерное моделирование. Это сегодня главным образом Python и проблема двух языков, но конкурентом там потихоньку становится Julia. Поэтому можно думать о том, чтобы сделать eDSL как набор различных разогнанных на GPU FOL/HOL солверов по примеру DifferentialEquations, JuMP и Modia.

3. В языках важна их сахарность (этот тезис подробно развивал justy_tylor). По формальным моделям есть множество "эквивалентностей", но вот людям или удобней, или неудобней какие-то конкретные синтаксисы, а уж что там потом делает компилятор, преобразуя из удобного для хорошей нотации формализма в удобный формализм для быстрых вычислений -- это дело компилятора. Если нужно преобразовавать в триплы, то пусть солвер FOL это преобразует и оптимизирует где-то там внутри себя, а на поверхности должны быть паттерны, n-арные предикаты (я помню весь ужас перехода от триплов к представлению паттернами -- заборы и коровники на много частей стандарта). Язык с плохим синтаксисом и хорошей семантикой проигрывает языку с хорошим синтаксисом и плохой семантикой. Поэтому возможность "нотационных расширений" важна. Среди таких расширений можно назвать Prolog DCG как пример компактности "из ниоткуда" для парсинга (DCG -- https://www.metalevel.at/prolog/dcg или DCTG — http://cmsmcq.com/2004/lgintro.html, и можно поглядеть ещё работы по проекту FONC O-Meta с теми же целями "минимальный язык для парсинга", но там не FOL а хитро понимаемая объект-ориентированность -- http://tinlizzie.org/ometa/), какой-то синтаксис для possible worlds (и тоже в VPRI были работы на эту тему -- http://www.vpri.org/pdf/m2013002_experiments.pdf). Так что языко-ориентированность в том числе и нотационная -- она важна.

4. Ну, и eDSL для моделирования/simulations, всяческих микротеорий -- синтаксис, типы, солвер для модели. Это понятно, это не обсуждается. Пример тут Modia для инженерного моделирования. С этим всё понятно, тут нет особых вопросов.

Итого: нужно смотреть на то, что происходит с языками представления знаний: всякими knowledge graphs до того момента, когда их вливают в нейросетки -- какие там языки представления графа, что там с выводом, как ускоряют вывод. Отдельно алгоритмы, отдельно разгон на GPU -- хотя это связанные вопросы обычно). Последние интервью Дугласа Лената говорят о том, что там продолжается линия на "мы разгоним FOL с HOL над knowledge graphs с микротеориями и прочими хитростями до приемлемых времён, и таки победим всех, ибо common sense и причины таки у нас".

Но иметь какой-то eDSL проект по представлению знаний (солверы FOL-HOL, посаженные на GPU) в Julia, напоминающий JuMP и DifferentialEquations -- это было бы интересно.

Самый большой риск: логические языки все эзотеричны, они ещё более эзотеричны, чем функциональные языки (про Curry-Howard помним, да), и языки представления знаний в классической чисто логической традиции выражения FOL поэтому рискуют быть такими же эзотеричными, как Пролог или CycL сотоварищи. Другое дело, что SQL это и FOL и тьюринг-полный язык, так что необязательно речь идёт о чём-то страшном-страшном. Так что там могут быть "форматы представления FOL" и собственно FOL-солверы. Но это детали.

Всё одно дело мутное. Эти самые вопросы с foundation ontolgy и upper ontology и выражением микротеорий (что нарушает всю "консистентность вывода" в рамках программы -- и нужны средства работы с микротеориями, которых нет в существующих системах типов языков программирования, плюс коммуникационные вопросы по обмену/федерированию знаний в этих микротеориях), похоже, нужно искать таки в языках знаний, а не языках программирования или языках программирования баз данных. И прикручивать болтами к экосистеме deep learning, NLU и прочим пришельцам из вычислительной математики. Так что пока меня не убедили, что в Julia это всё делать бессмысленно. Наоборот.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216135078543760
Monday, August 26th, 2019
2:52 pm
Big Neuro: триллионы транзисторов на чипе, квинтильоны и квадрильоны операций в секунду
Буквально за несколько лет мы пришли в мир Big Neuro -- в коннективистских архитектурах, то есть "нейросетях" счёт переходит с миллиардов/гига на триллионы/тера и даже квадриллионы/пета, а пока изредка и квинтиллионы/экза (короткая шкала -- https://ru.wikipedia.org/wiki/Системы_наименования_чисел).

Самый большой чип ускорителя для нейросетей -- это 1.2триллиона транзисторов на 42тыс.мм2, Cerebras Wafer Scale Engine компании Cerebras Systems, изготавливаемый на фабриках TSMC -- https://venturebeat.com/2019/08/19/cerebras-systems-unveils-a-record-1-2-trillion-transistor-chip-for-ai/, https://www.forbes.com/sites/tiriasresearch/2019/08/20/ai-start-up-cerebras-develops-the-most-powerful-processor-in-the-world/#26b4e5a86592. Это в 57 раз больше, чем чип V100 фирмы NVIDIA с 21млрд.транзисторов на 0.8тыс.мм2. Скорость обмена данных с памятью -- 9петабайт/сек, ещё одно Big. The energy cost of communication in this architecture is well under 1 picojoule per bit, which is nearly two orders of magnitude lower than in graphics processing units. В компании Cerebras Systems работает всего 194 человека (хотя мы и не знаем, сколько у них разработчиков было в подрядчиках, тем не менее -- это ли не восхитительно?!).

Конечно, это не сравнится с суперкомпьютером. Так, Summit (запущен в эксплуатацию год назад -- https://blogs.nvidia.com/blog/2018/06/08/worlds-fastest-exascale-ai-supercomputer-summit/) имеет 27648 NVIDIA V100 и 200петафлопс (умножений плавающей) и 3exaops, экза/квинтиллионов операций умножения-сложения целых в секунду -- это помньжьте "пета" ещё на тысячу, миллиард миллиардов. At 200 petaflops — If everyone on Earth did 1 calculation/second, it would take 1 year to do what Summit does in 1 second. At 3 exaops of AI — If everyone on Earth did 1 calculation/second, it would take 15 years to do what Summit can do in 1 second. А сколько занимает места этот Summit? Два теннисных поля! Следующий за V100 чип для текущего нейро-поколения AI -- это Huawei Ascend 910, который имеет удвоенную производительность (закон Мура продолжается для GPU!), но это всего вдвое, 0.25PFLOPS, 0.5PTOPS, по факту того же класса чип -- https://medium.com/syncedreview/huaweis-first-commercial-ai-chip-doubles-the-training-performance-of-nvidia-s-flagship-gpu-86e4d0078f6f

Cerebras Wafer Scale Engine это всего один чип, хотя и потребляет он 15Квт на свои 400тыс. AI вычислительных ядер -- примерно столько же, сколько потребляло бы эквивалентное количество одиночных чипов. Чудес-то не бывает, вычисления требуют энергии.

Самая скандальная языковая модель (модель языка в нейросети) была скандальна ровно потому, что она оказалось достаточно большой, чтобы произвести нетривиальные результаты -- это GPT-2 от OpenAI, которую даже отказались публиковать из-за боязни злоупотреблений в использовании. В ней было 1.5B параметров, 0.0015P. Только что опубликовали сокращённую вдвое модель -- https://venturebeat.com/2019/08/20/openai-releases-curtailed-version-of-gpt-2-language-model/. Но десятые триллиона уже никого не останавливают, только что опубликовали независимо реализованную языковую модель такого же масштаба с практически такими же результатами: https://medium.com/@vanya_cohen/opengpt-2-we-replicated-gpt-2-because-you-can-too-45e34e6d36dc. Потолок цены тренировки такой модели -- $50К, и есть много возможностей снизить цену -- основная цена это те самые чипы и электроэнергия на их работу, сколько на их охлаждение.

И этих чипов нужно много. Чтобы обучить языковую модель BERT всего за 53 минуты потребовалось 1472 GPU V100, это 92 компьютера DGX-2H ценой $399тыс., то есть там только аппаратуры для этого почти часового счёта на почти $40млн, https://devblogs.nvidia.com/training-bert-with-gpus/). И это не самая большая модель! В работе по этой же ссылке https://devblogs.nvidia.com/training-bert-with-gpus/ указывается, что была натренирована модель GPT-2 на 0.0083 триллиона параметров, при этом достигли 15.1 PetaFLOPS sustained performance!

Конечно, речь не идёт о том, чтобы заниматься сетями на 1 триллион параметров. Но если речь идёт о какой-то модульной конструкции из сотни (возможно, совсем неодинаковых) сетей (и, возможно, совсем не сетей) на 0.01 триллион параметров каждая -- то вот такая когнитивная архитектура явно сможет много больше, чем текущие даже самые большие сетки.

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

А дальше Big Neuro сочтут маркетинговым термином, под которым будут понимать что угодно. Очень скоро будут обсуждать, как и с Big Data, что дело не в размере, а volume, veloсity, veracity, variety, value, variability (https://www.researchgate.net/figure/Six-Vs-of-big-data-value-volume-velocity-variety-veracity-and-variability-which_fig15_280124446) и ещё больше каких-нибудь V. И все формулировки можно будет брать из BigData, и все маркетинговые слоганы.

Но технологически это новый чудесатый мир, где если недостаточно мозгов, то просто добавь транзисторов. А если достаточно мозгов, то тоже добавь транзисторов.

Следующая история, конечно, про симуляторы мира. Чтобы обучить нейросетку, нужно построить виртуальный мир -- и обучать дальше сетку в этом мире, ибо в виртуальном мире эволюция идёт быстрей, чем в реальном мире. Нужно много-много симуляторов. Следующая большая история -- это логические вычислители, которым тоже хочется аппаратной поддержки (вот примеры работ, которые пытаются ускориться на текущих архитектурах вычислений -- https://arxiv.org/abs/1810.06617 и https://www.cyc.com/wp-content/uploads/2015/04/AAAI-SharmaA.1646.pdf, и такого много. Вполне возможно, что тут как с нейронными сетями поможет задействование аппаратного ускорения для получения нетривиальных результатов). Понятно, что будут попытки "повторить мозг" -- перенести логические вычисления в нейронные сетки (neural logic machines -- https://arxiv.org/abs/1904.11694, embedding of knowledge graphs -- https://arxiv.org/abs/1908.07141 и т.п.), равно как моделировать физику не уравнениями, а прямо нейронной сеткой -- https://ai.facebook.com/blog/phyre-a-new-ai-benchmark-for-physical-reasoning/. Смогут ли текущие ускорители AI на нейросетках сработать для этих же задач так же качественно, как могли бы сработать специализированные компьютерные архитектуры?

Ответ прост: нет, не смогут. Алгоритмы там везде разные, поэтому работает теорема бесплатного обеда: тот вычислитель, который хорош для одних задач, будет ужасен для других задач. Так что нейровычислитель будет хорош только "в среднем по больнице". И мы увидим в ближайший десяток лет ещё много разного и чудесатого -- и аналоговые спецвычислители, и универсальные цифровые архитектуры (для препроцессинга и постпроцессинга видео, физических вычислений, логических вычислений, вероятностных вычислений, а также и для вычислений в deep learning). Жизнь уже интересна, счёт транзисторов пошёл на триллионы -- и спецвычислитель BigNeuro на триллион транзисторов может сделать команда из меньше чем 200 человек.

А пока болеем не за динамо и спартак, а за участников этого чемпионата искусственных мозгов -- aNLI, https://leaderboard.allenai.org/anli/submissions/about. Это продолжатели дела CYC, они хотят закодировать common sence, здравый смысл. И сделали на эту тему соревнование. Рассказ про abductive commonsence reasoning -- https://arxiv.org/abs/1908.05739. У людей в этом соревновании 92.9% правильных ответов. У нейросетки BERT Large Finetuning -- 66.75%. У CYC (там ведь как раз цель соревнований была дизайн-целью) -- неизвестно, у IBM Watson (это ж победитель "Jeopardy!", по сути это ж то же самое) -- неизвестно. Но там много-много лет ручного кодирования знаний, а BERT тренируется, как мы знаем, за 53 минуты (грубо говоря, читает за это время в себя если не всю Библиотеку Конгресса, то сравнимый объём текста). А ещё было бы забавно увидеть соревнующимися там не только нейросетки и логические вычислители, но и людей. Скажем, команда победителей что-где-когда сколько бы решила в этом соревновании? Не смогла ли выдать больше ли 92%? С другой стороны, и это соревнование тоже ни о чём: нобелевские лауреаты и крутые политики обычно не эрудиты, а эрудиты и другие победители викторин не так уж и заметны в других сферах жизни. Но мы всё равно болеем.

Но причём тут Big Neuro и решение задач, объявленных в этом соревновании по использованию здравого смысла в рассуждениях? Напомню тезис Rich Sutton (http://www.incompleteideas.net/IncIdeas/BitterLesson.html): прогресс в AI определяется доступной вычислительной мощностью при простых алгоритмах. Размер решает. Текущая самая большая нейросетка GPT-2 8B пока всего в 24 раза больше BERT, текущего победителя соревнования по объяснениям на основе здравого смысла. И хотя понятно, что с этой архитектурой существенно улучшить результат не удастся, то альтернативные более успешные архитектуры вряд ли будут с меньшим количеством вычислений. IBM Watson, победивший в Jeopardy! -- это прежде всего суперкомпьютер! Big Neuro таки решает, а если там пойдёт ещё и Big Simulation и Big Logic, которые сольются в какой-то момент в Big Evolution Multi-engine, то аж дух захватывает, что может получиться!

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/groups/nevronet/permalink/1406594802840170/

Краткое содержание поста:
-- есть no free lunch тезис, что разные алгоритмы для разных задач имеют разные оценки времени
-- Sutton говорит, что побеждают простые алгоритмы при масштабировании. Типа нейросеток, когда их посадили на нормальный "их" кремний.
-- есть ряд классов алгоритмов, которые могут помогать решать разные задачи с интеллектом. Логика, эволюция.
-- по идее, должна быть когнитивная архитектура, которая позволяет использовать такие алгоритмы, маршрутизируя им соотвествующие классы задач
-- не факт, что их все нужно выполнять на нейро-инфраструктуре.
-- это означает, что перспективно попробовать ускорители и для логики, и для физики, и для эволюции в конечном итоге (где потребуется интеграция всех ускорителей: эволюционировать-то должна будет когнитивная архитектура!).

А эволюция съест всю вычислительную мощь, которая доступна, и ещё потребует. Так что радуемся и имеем дело с Big Neuro и Big ВсёОстальное.
Saturday, August 24th, 2019
3:14 pm
Чат по типам в языках программирования, моделирования, представления знаний
Поскольку в чате "Zависимые типы в массы!" обсуждение моделирования жизни этими типами считается оффтопом (странно, но так), то был стартован другой чат -- в котором могут обсуждаться кроме зависимых типов самые разные типы и бестипья -- "Типы в языках программирования, моделирования, представления знаний", https://t.me/typeslife. И там сразу какая-то дискуссия, с самого начала (за первый час в чат пришло более двадцати человек).

Но и эти типы в языках (а хоть и программирования, моделирования, представления знаний (онтологизирования). А я бы ещё предложил и типы в коннективистских структурах, типа нейронных сетей. "Линейщина", как там ласково называют любые переходы к недискретной математике -- от quantitative type theory https://bentnib.org/quantitative-type-theory.html до собственно дифференцируемых типов в дифференцируемых программах по линии рассуждений "дифференцируемое всё. от чёрно-белой модели мира к рябенькой" -- https://ailev.livejournal.com/1464563.html.

Больше типов богу типов!

Но мой вопрос, поднятый в "Типы языков программирования как foundational ontololgy" https://ailev.livejournal.com/1485657.html и далее развёрнутый в "Foundational ontologies -- типы в языках программирования против БД" https://ailev.livejournal.com/1486211.html про state of the art систему типов как foundation ontology пока остаётся неотвеченным: разные системы типов разбираются сами по себе, чаще всего без обсуждения того, как они хороши в качестве foundation ontology (то есть хороши вместо объектов из ООП, табличек из реляционной алгебры, триплов из логики первого порядка и т.д.).

Я вообще уподобил эти системы типов CISC и RISC архитектурам процессоров. Простые системы типов точно так же побеждают "по очкам", как RISC процессоры в процессорной архитектуре.

Ну, и дальше -- как делать DDD с этими complex type systems или reduced type systems, это ж современная форма онтологической работы. Моделировать в языке программирования и API, или сразу делать концепутальную модель данных для базы данных и как её потом транслировать в физическую модель данных для конкретной базы данных и/или языка программирования. И как там быть с программированием/моделированием/онтологизированием-в-большом (см., например, материалы по ссылкам в https://ailev.livejournal.com/1391038.html).

Сейчас всё больше и больше людей занимаются по факту онтологией, но не знают об этом. Ну, типа "говорят прозой", но не знают слова "проза". Фишка в том, что ещё непонятно, где знание прирастает быстрее — у самих computational ontologists или в этих смежных областях.

Вот люди из NLP с deep learning пришли, и почти вся допотопная вычислительная лингвистика пошла лесом ))) С классическими compotational ontologists вполне может быть подобная история.

Так что я бы про онтологию как практику привязки моделей к жизни говорил, а вот про онтологов — уже с большой осторожностью. Люди, занимающиеся DDD занимаются онтологией, хотя и кулибинствуют вовсю. И люди, делающие классификаторы с нейронками, тоже занимаются онтологией, и тоже кулибинствуют. А ещё есть классические формальные философы (которые с формулами, но без языков программирования — типа "математики в её связи с миром"), так они тоже занимаются онтологией — типа David Lewis с его possible worlds. Онтология при этом, конечно, должна сильно поменяться, когда ей занимаются все, кому не лень. Она и меняется.

Кому интересно -- разговаривают об этом вот тут (https://t.me/typeslife).

Для меня это важно в связи с SysMoLan (например, https://ailev.livejournal.com/1449992.html -- про онтологический статус объектов SysMoLan, про систему его типов) и в связи с планирующимся курсом вычислительного мышления, где нужно будет говорить про state-of-the-art в типах -- https://ailev.livejournal.com/1477090.html

UPDATE: меня очень волнует набор типов из моего учебника системного мышления, гармонизированный с IEC81346. К этому модель HQDM будет поближе, но всё одно нужно разрабатывать эту upper ontology отдельно — инженерная и менеджерская жизнь-то с этим системным мышлением чуток поменялась. И это нужно в upper ontology учесть.

Ну, и какую систему типов, сиречь foundational ontology мне для этой концептуальной/методлогической работы выбрать?

Вот это мой вопрос!
Friday, August 23rd, 2019
6:27 pm
Foundational ontologies -- типы в языках программирования против БД (2/2)
Окончание. Начало текста в https://ailev.livejournal.com/1486211.html

[но триплы или FOL -- это язык для представления результатов, но не ведения самой онтологической работы. Формального языка для обсуждения физического смысла, приговариваемого к уравнениям, нет. С онтологией те же проблемы]
Абсолютно так. Ровно те же проблемы. При этом "смысл около, описанный комментариями" — это так не должно быть. Для меня это всё как-то связано со схемами причинности, где за последние лет пятнадцать произошла революция (там всё было формализовано, говорят теперь о причинном выводе — то есть там смогли навести логику, см. https://ailev.livejournal.com/1435703.html).

То есть у нас есть прагматика (для чего это всё), причинный вывод (те самые "связи в комментариях"), рассуждения по абдукции и выучивание модели мира для объяснений (вот свежее соревнование — https://leaderboard.allenai.org/anli/submissions/about), большие базы знаний common sense для всего этого и foundational ontologies для быстрой обработки.

При этом, похоже, методы работы крайне разнятся, когда нужно интегрировать данные нескольких разных проектов (базы данных, где foundational ontology делается сейчас таблицами, и идёт разгон скорости за счёт работ типа СQL) и просто сочинение произвольных foundational ontology в виде самых разных систем типов языков программирования с весьма эпизодическим понимание, нафиг оно вообще нужно при работе программиста, моделирующего мир на всём это разнообразии (ибо те, кто разрабатывают все эти типы, обычно решают олимпиадные задачки in the small, и им фортранных типов бы хватило с головой для моделирования мира. Ну, и паскалевских структур, но и их могли бы заменить common blocks в фортране — там же по факту за счёт этих common blocks был реализован пакетный язык, а не "просто императивный", весь этот поход на модула и ада был не нужен по сравнению с тем же паскалем с аналогом common blocks, вот и не взлетело). ООП как раз выросло из того, что предлагалось не "держать комментарии в уме", а прямо моделировать понятия мира объектами — и для in the small это хорошо шло. Про триплы же не пошло ввиду отвратительной производительности субд с этой foundational ontology со стороны "математики" и плохо продуманных средств работы с онтологическими паттернами со стороны выражения моделей мира (ибо триплы это оказалось как ассемблер, а как поднимать уровень языка сразу не договорились, и прошло очень много времени, пока хоть какая-то договорка прошла. Но после этого всё сдохло, ибо эти "онтологические паттерны" для выражения мира плохо клались на триплы, всё в аппаратуре было медленно и печально как по памяти, так и по времени — часть этих проблем описана в https://justy-tylor.livejournal.com/171175.html).

То есть для меня это всё история про связь foundational ontology и upper ontology — их вечная нестыковка. При этом в upper ontology научились тоже как-то модуляризировать их, "микротеории" делают. А в foundational ontology если мультипроект, то базы данных, а если "просто программа", то вообще системой типов не заморачиваются и работают на чём есть (ну, или "безумные инженеры" пытаются выдумать, зачем вообще нужны их навороченные типы, хотя хватило бы типов паскаля для большинства целей, а все навороты — это для одной-двух "фишек" в программе). Работы типа использования типов в F# для онтологического моделирования https://pragprog.com/book/swdddf/domain-modeling-made-functional — это большая редкость, ибо в задачах с использованием DDD сразу предполагается работа с СУБД, а не работа внутри программы. Но объектные СУБД при этом накрылись медным тазом (идея о том, что система типов в БД и в программах должна быть одна и та же — конечно, ООП, если везде было только ООП). И с тех пор эту идею никто не поднимал на щит опять. Типы в базах данных развиваются отдельно, в языках программирования отдельно. Связь между ними держится "в уме", теми самыми "комментариями в голове программиста", как комментарии физика держатся в голове для уравнений математики в его задачах.

Вот пример такого рассуждения, связывающего "вершки и корешки", тот же Валерий Крылов два дня назад: "В принципе, за прошедшие с нашей .15926-движухи годы я ни разу не видел успешного применения подхода 4D (выделение темпоральных частей и их реификация, как в ISO 15926) или подхода 3D+1 (реификация отдельных фактов, как в Gellish) на практике. Кому нужны лишние джойны и медленные запросы к базе данных? Никому. Поэтому используется 3D с прошивкой времени прямо в факты под конкретные задачи, благо с появлением фич из temporal databases в SQL:2011 это стало ещё немного удобнее. И в рамках отдельных микротеорий это самый правильный подход" (это в дискуссии к начальном посту данного треда про онтологическое моделирование "на типах в языках", а не "на базах данных" — https://ailev.livejournal.com/1485657.html).

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

[хотите сделать онтологический клей? так в чём проблема всё-таки?]
Обычно мне требуется некоторое время для объяснения сути дела — наличие проблемы ещё и с трудом признаётся. То есть в разговорах эта проблема обсуждается (куда ж без неё, программировать-то надо), а в книгах и статьях — нет. Разные тусовки, занимающиеся онтологиями, базами данных, типами в языках, соответствующей математикой — они эту проблему не видят, посколько она "на стыках".

"онтологический клей" — я думаю, это такое высказывание о задаче интеграции данных жизненного цикла, когда есть что склеивать этим клеем. А я говорю ещё и о том, что хотел бы понимать, как написать декларации типов для решения задачи в какой-то предметной области. Учебники по тому, как это делать для реляционных баз данных есть. Как это делать для графовых баз данных — появляются потихоньку. Как делать для программ безо всяких баз данных (с persistance, например) — мне показали на один, для F#. Но это не общий рассказ про то, как делать такую работу в языках программирования. При этом если взять ООП — то там опять всё радостно появляется, ну так за тридцать лет могло и появиться. Но почему-то ООП базы не выжили, и в языках программирования тоже ООП сегодня только ленивый не пинает — то есть не так уж и хорош этот подход к моделированию мира оказался.

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

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

У онтологов и людей из баз данных есть соображения о том, как описывать мир (у онтологов на уровне концептуального проектирования, у разработчиков баз данных на уровне приземления концептуальных моделей данных на реляционные главным образом, или на графовые структуры). А у программистов ничего про мир не говорится, про приземление концептуальных моделей на типы не говорится. И эти дилетанты в моделировании данных, но профи в алгоритмике и математике моделируют мир уж как могут, "исходя из опыта". А вот про алгоритмику у них наука! И про типы без относительно того, что ими выражать (ими ведь мир описывают, без этого они не нужны) — тоже наука. А вот как описывать мир этими типами — нет науки. Вот мне надо описать работу атомной станции со всех сторон (чертежи, режимы работы реактора, штатное расписание персонала и т.д.). Я её реляционной моделью данных должен описывать, одним из вариантов ООП или каким-то вариантом использования зависимых типов? Молчание мне ответом. При этом люди из БД победят — они сразу скажут, что данных много и с ними будут работать сразу много программ. И все ваши зависимые типы и ООП и даже некоторая часть онтологов (но не все, там мостик-то протоптан некоторый) отвалятся по факту.

Ну вот SAP — это про базы данных, и там "из коробки" есть модель данных на примерно 30тыс. табличек. Это некоторая модель предприятия. При этом, скажем, если у тебя нужно описать каталог оборудования и (что неправда) каждый вид оборудования описывается одной табличкой, то 15тыс. видов оборудования (это очень маленький каталог!) описываются сразу 15тыс. табличек, и запросы к такой базе начинают быть грустными. При этом, конечно, как-то изгаляются: на реляционной модели пишут какую-то другую "наложенную объектную модель" (чаще всего объектную, ибо других вариантов не знают) и как-то уже заполняют всю базу в соответствии с этой моделью. Потом скорости не хватает, и пишут прямо поверх этой модели в исходные таблички, наступает бардак. Но вот обработка ведётся где-то в "бизнес-логике", внутри программ. А программы пишутся на "обычных языках программирования", и дальше идут запросы в базу данных, переконвертация из типов базы данных в типы языка программирования, а затем вычисления для предметной области обработки этих данных (что-то там в коропоративной аналитике, например) в самом языке программирования и затем выгрузка результатов назад в базу данных. Всё это сопровождается головной болью по поводу синхронизации работы разных программ над этой базой данных (кто-то ещё читает, а кто-то уже пишет туда же), распараллеливания работы (считать-то много, параллельность выполнения запроса к базе, дальше параллельность обработки выгруженного), часть вычислений уходит в GPU-ускорители баз данных, часть в GPU-ускорители для операций с массивами языка программирования, и весь этот весёлый бардак с перегоном из формата в формат для вроде бы копеечных обработок весело журчит и булькает часами, и энтерпрайз прямо на глазах становится кровавым. Перегонка СУБД в оперативную память помогает, но не сильно — там всё плохо архитектурно, так что это просто "механическое ускорение", оно не из первых принципов. Так что SAP очень, очень хороший пример того, как всё печально)))

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

Так что там нет ответа на мой вопрос. Там foundational ontology — реляционная модель данных, или ER-модель (entity-relationship). А я говорю, что можно ли использовать систему типов языка программирования как foundational ontology — есть ли где такие работы? В ответ пока слышу, что "в основе всего множества и отношения, то есть графы. Графы упаковываем в таблички, получаем реляционку. Потом делаем запросы или на SQL, или для пущей оптимизации на CQL". Ну, это может быть одним из ответов. Но тогда я перестаю понимать, почему программисты не используют реляционные структуры прямо внутри программ, а используют навороченные системы типов, включая зависимые! Зачем им богатые системы типов, если в основе только отношения и функции, и они отличненько выражаются графом, а граф выражается табличками, а с табличками уже работает даже Excel и уж тем более SQL или его математизированный родственник CQL? ))) Я уж совсем утрирую, но в каждой шутке есть только доля шутки )))


Меня не интересуют SQL базы данных с реляционной моделью данных как foundation ontology. Я спрашиваю, зачем мне вообще эти базы данных, если у меня есть много более богатые системы типов для описания мира мимо реляционного представления — и я могу выражать сложные описания мира в типах языков программирования много более кучеряво, чем в реляционных табличках. А если мне скажут, что это неуниверсально, так я отвечу, что для доступа к значениям типов в языке программирования у меня есть сам этот язык — и уж он всяко будет не хуже языка запросов, он ведь как раз для обработки данных, упакованных в этих его кучерявых типах придуман!

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

Делают также попытки работать только в типах языка программирования, выгружая и закружая прямо дампы памяти для persistance. Существует уже куча бинарных форматов для этого (ибо XML и JSON тут опять же не помогают, а только мешают — выедают время, память и мозги на организацию кодирования-перекодирования при чтении-записи бинарных данных типов языка в текстовое представление). Но и там есть свои засады. В том числе то, что написанное одной программой становится трудно писать другой программой. Казалось бы, почему? Ведь в базах данных всё то же самое — но читают же! А тут типы языков программирования — но чтение оказывается по факту невозможным! Тут тоже отдельная история, но пока эта история маргинальна. Но она уже есть, ибо накладной расход на СУБД при нынешнем отсутствии ограничений на оперативную память и тренде на обработку в оперативной памяти уже игнорировать становится нельзя.

Ну, а понятные проблемы, о которых вы тут пишете, примерно в этих же формулировках обсуждались и десять лет назад, и в чуть более мутных — двадцать лет назад. Так что ждём-с прорыва. ))) Вот мой прежний плотный набег на тему был где-то в 2012 году, я и поинтересовался, что с тех пор произошло. Похоже, что особо ничего и не произошло. Ну вот Julia появилась с не-ООП моделью, а multiple dispatch и своей хитрой системой типов. Но там тоже онтологическая работа с этими типами не описана, хотя есть любопытные ходы на работу с моделями и DSL как таковыми на базе макроса @model — есть даже что-то типа инструкции, как писать DSL на Julia: https://julialang.org/blog/2017/08/dsl

Но в целом — продолжаем ждать каких-то результатов, идут исследования, это я из дискуссии уже понял.

[а почему вы не сформулируете проблему формально?]
А вы разве сомневались, что я не буду наводить тут формализм? Ибо формализм это обычно сжатие информации — и непонятно, что в ходе обсуждения окажется важным. Вот дообсудим, и будет формализм. А пока его нет — естественный язык.

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

Эх, были бы нормальные формализмы, я бы тут эти тексты не писал, а просто ими пользовался!

[так нету ещё "категорий и гомотопий из коробки", чтобы помочь с выражением онтологий!]
Мне ж необязательно именно "категории и гомотопии". Вдруг ещё что-то интересное появилось из новенького? Ну, и десяток лет назад ровно такие ответы были, мы ж тычемся в эту тему довольно давно. Когда мы начинали работать с ISO 15926, то вместо триплов одним из вариантов формализма рассматривалась теория категорий — вот, например, я писал об ISO15926L как языке программирования с логическими/категорными вычислениями, и там же ISO15926 по идее А.Власова рассматривать ISO15926 как язык описания типов в языках программирования, если к онтологии добавить языковую компоненту (ровно та же тема, что мы обсуждаем сейчас, и что вы говорите, "идут исследования как такое делать"). Прошло 9 лет с этого поста — и всё в том же печальном виде, "исследования идут" ))) Вот: https://ailev.livejournal.com/831024.html

[Так типы -- это не как строить мат.модели для мира, а как эти модели описывать!]
"В каких терминах математические модели описывать" — это как раз foundational ontology. Холст, на котором всё рисуется. Меня как раз этот ответ-то устраивает! А потом отдельно — про сами математические модели, как в них моделировать — это онтология, как upper ontology (понятно какую) нарисовать средствами foundational ontology.

Фишка в том, что John Sowa предлагает онтологии, у которых нет foundational ontology c понятными над ней вычислениями называть не онтологиями, а терминологиями — ибо там можно брать слова-термины для неформальных рассуждений. А в онтологиях можно брать термы для формальных рассуждений.

Но как я понял, устаканненных каких-то формализмов нет, и самый супер-пупер вариант — это предложить онтологам для их математических моделей задействовать разогнанную реляционку с теоркатегорным языком запросов в CQL, или намекать, как заюзать конкретный аппарат типов F# для подобной работы в DDD, но вот каких-то общих рекомендаций для подобной работы нет — "исследования идут". Ну да, десятки лет уже идут, ждём-с.

А пока катит новая волна из deep learning со всем вероятностным и дифференцируемым и многомерным: концепты (те же типы) как вектора в многомерном пространстве, вероятность отнесения к типу, выучиваемость типа вместо его программирования и т.д.. И все эти онтологии и "графы знаний" теперь массово грузят уже не в типы программ на языках программирования, а в нейронную сетку. То есть пока линия исследований в теории категорий рожает, появляется совсем новая линия этой же работы на других совсем механизмах и других идеях. Посмотрим, какая линия родит быстрее (моё мнение — должен появиться какой-то гибрид, но пока исследования идут независимо).

[так богатые системы типов нужны только для программирования функций и процессов! строгость нужна для доказательства правильности этих программ!]
Но зачем тогда супервыразительные системы типов, если моделировать нужно только функции и процессы?! В моделировании мира, кстати, тоже есть моделирование функций и процессов — но их упихивают в те же таблички!

И вот тут есть некоторая проблема с поворотом мозгов. В инженерии есть два способа работы с функциональными описаниями: через функции (ролевое поведение) и через ролевые объекты (которые себя ведут, т.е. функции у них). Функции выражаем отглагольными существительными, а ролевые объекты — просто существительными. А потом замечаем, что в языке существительных миллионы (включая спецтерминологию многих предметных областей). А вот глаголов всяких десяток тысяч основных, максимум тысяч тридцать. Более того, про глаголы люди думать толком не умеют, ибо с трудом их представляют (про поведение думать обычно очень контринтуитивно). А про вещи — думают на раз-два. При этом то самое 4D это попытка функции превратить в объекты (поведение определяется как взаимодействие участвующих вещей, отношение участия это специализация отношения часть-целое в 4D, в том числе речь идёт о темпоральных частях, то есть части во времени aka состоянии). То есть разнообразие мира, требуемое для коммуникации людей по всему множеству проблем, всё-таки упирается не в разнообразие функций, а в их одинаковость, но разнообразие связанных с ними вещей. Поэтому на нижнем-то уровне всё может жужжать в терминах отношений и функций, а вот на верхнем по необходимости должно представляться вещами — и вот тут и может быть зарыта собака. Если дать удобные средства конструирования из этих отношений и функций ролевых объектов — будет понятно, как представлять мир. А пока там "отношения и функции до самого низа", вещи представляем табличками, между табличками прописываем отношения, приговариваем к ним возможные функции (подразумеваемые). А потом уровнем ниже жужжим на языке программирования этих функций и отношений. А сахар выразительности для ролевых объектов остаётся уделом ООП, реляционок и прочих удобных для них систем моделирования. Но что-то мне подсказывает, что так рассуждать про современные системы типов неправильно. Хотя всё сказанное ну очень выглядит правдоподобно. Смотрит онтолог на мир, видит вещи и немного отношений (об этом ему говорит в теории концептов так называемая theory theory, я давал ссылку). Смотрит на описание типов в языке программирования — там ничего этого нет, и нет инструкции, как проще такое кодировать. Он идёт к спецам по моделированию данных в СУБД и они описывают ему реляционную модель. Он хватается за голову и идёт к триплам. Сильно легчает с головой, но проблема с памятью и временем исполнения — и приходится возвращаться к реляционкам. В общем, куда ни кинь, всюду клин )))

И чтобы не допускать неправильные композиции функций и процессов -- для этого не супервыразительность нужна, а вроде как обратное свойство -- набор ограничений ))) Для меня "нет выразительности — нет проблемы ограничивать лишнюю выразительность" ("нет головы — нет проблемы"). Или это выразительные языки ограничений для описания ограничений-утверждений типа https://en.wikipedia.org/wiki/Object_Constraint_Language ?

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

Про строже это понятно в части правильности, непонятно про выразительность. Чем более выразительная типизация, тем более разные объекты можно описывать этими типами. Самая выразительная в мире система типов лучше всего опишет разнообразие предметов окружающего мира. Значит, её хорошо использовать для описания окружающего мира во всей его полноте? И тут прошедшая дискуссия говорит, что нехорошо — описывай мир реляционной алгеброй, а наши богатые типы мы будем использовать для доказательства правильности программ исполнения реляционной алгебры. Зачем для программ исполнения реляционной алгебры супервыразительность в типах? Я понимаю про строгость в типах для этих целей, но выразительность-то для этого воробья зачем? А за описанием мира во всей его полноте не гонимся, что ещё хитрого можно в мире описать новыми хитрыми подвывертами в системе типов не думаем. Вот это мне странно.

Почему вся выразительность используется не для выражения нюансов описаний окружающего мира, а только для ограничений неправильного поведения?! Для ограничения неправильного поведения достаточно очень ограниченной выразительности. Но если у нас выразительность повышенная, то почему мы тогда отказываемся говорить об описании мира, а только говорим об ограничениях неправильного поведения? Это как иметь алфавит с 500 буквами и говорить, что им нужно не мир описывать, а чистить ошибки в описании мира алфавитом из 5 букв. То есть имеем богатейшую систему типов, и используем её для описания программ обработки реляционных баз данных с реляционными описаниями мира, но не для ведения баз данных с богатыми по типам описаниями мира. Почему?

Я понимаю, что для выражения богатства мира нужна богатая система типов. Это я пытаюсь ярко продемонстрировать противоречие, которое мне тут рассказывают: что богатство типов нужно только для поддержки скоростных вычислений внутри БД с небогатой системой типов. Моя позиция как раз в том, чтобы брать языки с хорошей типизацией, и прямо на них писать модели предметной области — как наборы объектов и отношений, так и работающие с этими объектами и отношениями функции. Те самые DSL, взаимодействие между объектами которых обеспечивается хост-языком. Так сказать, не объект-ориентированность, а DSL-ориентированность. И богатая система типов нужна для выражения объектов и отношений в DSL. И для DSL могут быть какие-то онтологические guidlines в части описания объектов окружающего мира (DDD для меня это как раз маленькая часть таких guidlines). Но это моя гипотеза.

В жизни же DSL вдруг оказываются микросервисами с такими API, что с типизацией там фейспалм, а онтологизация там ad hoc.

И вся онтология уходит в концептуальные модели данных для базы данных, но не в концептуальные модели данных для языков программирования.

И трёхслойка (про концептуальную схему данных, логическую схему данных и физическую схему данных) известна для баз данных, но не для языков программирования. А ведь физическая схема данных — это оно и есть: как вся эта этажерка на основе upper ontology описывается в терминах поддержанных машиной вычислений на foundational ontology. И я возвращаюсь к изначально заданной теме: вот почему не рассказывается массово, как объекты мира выражать в терминах современных систем типов? Про ООП такого было и есть много, но БД на идеях ООП провалились, и сами ООП сегодня не считаются таким уж state-of-the-art в выражении структуры мира (в том числе онтологами). Но других развитых систем типов для описания мира не предлагают. Меня вот этот вопрос мучает.

Типа как кто-то выращивает персики, виноград, арбузы всё новых и более сладостных сортов, а кушать все продолжают сырую пшеницу и жалуются, что живот болит. И никаких инструкций, как кушать те самые персики. Они разрабатываются вроде как из любви к искусству, для скрашивания уродливости мира, помещаются в музеи. Почему мир не моделируют в этих типах, а моделируют только обработки внутри БД?! Почему?!
6:24 pm
Foundational ontologies -- типы в языках программирования против БД (1/2)
Когда мы работали с ISO 15926, то вместо триплов одним из вариантов формализма рассматривалась теория категорий — вот, например, я писал об ISO15926L как языке программирования с логическими/категорными вычислениями, и там же идея avlasov рассматривать ISO15926 как язык описания типов в языках программирования, если к его онтологии добавить языковую компоненту -- это 2010 год, https://ailev.livejournal.com/831024.html. Прошло 9 лет с этого поста — и я высказываю обратную идею: не ISO 15926 как система типов в языке программирования, а типы языков программирования как foundational ontology для upper ontology (ISO 15926 или какая там ещё) вот тут, пару дней назад: https://ailev.livejournal.com/1485657.html. В том числе, почему бы и не какая-то система типов, происходящая из теоркатегорного подхода. И я пошёл в чат любителей dependent types (https://t.me/joinchat/Ai4h2D9SWO8GfISyv-CHsQ), где более 400 его участников рассказали мне, что "из коробки" решения никакого пока нет, а "исследования идут" (старт дискуссии был тут: https://t.me/c/1062361327/22873).

В ходе разговора, конечно, много чего всплыло:
-- как это всё связано с теорией концептов, в том числе theory theory
-- онтологическая работа как комментарии к формальным структурам на FOL -- это как физический смысл, приписываемый мат.уравнениям. Это похоже на схемы причинности и причинный вывод (subject experts рисуют схему причинности, а дальше проверки идут вычислениями).
-- дифференцируемые и вероятностные системы типов, выучиваемые типы против традици
-- бестиповые языки и почему они не выживают
-- как работа с типами связана с programming-in-the-large и programming-in-the-small
-- почему не выжили трипл-сторы
-- почему не выжили объектные базы данных
-- абсолютная безопасность как абсолютная непригодность для работы
-- почему богатые системы типов не используются для моделирования окружающего мира как foundational ontology, а вот убогие реляционные базы данных и даже ещё более убогие трипл-сторы активно используются. А богатые системы типов используются для программирования вычислений над убогими системами типов.
-- для F# таки нашлась книжка, описывающая как делать DDD с его системой типов -- https://pragprog.com/book/swdddf/domain-modeling-made-functional (частичный ответ на мой вопрос "как использовать богатую систему типов для моделирования богатого на сущности мира" -- но для частного функционального языка)
-- про табличные базы данных помянуто в Seven Sketches on Compositionality. An Invitation to Applied Category Theory -- http://math.mit.edu/~dspivak/teaching/sp18/7Sketches.pdf. Более подробно про compositionality (как понять целое высказывание, состоящее из связанных частей) и applied category theory см. в https://arxiv.org/pdf/1809.05923.pdf и https://plato.stanford.edu/entries/compositionality/
-- knowledge representation in bicategories of relations -- https://arxiv.org/abs/1706.00526
-- теория категорий для ускорения реляционных данных, CQL (categorical query language, https://www.categoricaldata.net/ -- open source, литература в https://www.categoricaldata.net/papers), с коммерческим решением по интеграции данных на его основе -- https://conexus.ai/
-- стек технологий, где задачи моделирования мира и вычислений над моделью строго развязаны: движки над foundational ontology это могут быть одни движки (все эти SQL, SPARQL и CQL), а вот вычисления над моделью делаются из языков программирования с их богатыми типами ad hoc
-- Использование теории категорий для моделирования модальностей в юридических контрактах: https://legalese.com/. Очень похоже на проект с такими же целями, как SysMoLan, только там для юридизмов — идеи с модальными логиками будут развиваться. Там, правда, у онтологов тоже есть предпочтения, модальности сегодня проще моделируются как раз классификаторами, то бишь теми же типами.
-- ... много всего по мелочи, я не писал сюда подробных ответов, больше собственные реплики. А полезные ссылки привёл прямо тут в предыдущих строчках.

Делать литературную обработку всего треда мне лень, но для архивных целей вытащу свои реплики сюда. Всё началось с перепоста:

-- Высказывается идея, что типы в языках программирования — это foundational ontology. А для upper ontology (в том числе 4D upper ontology) нужно просто сделать DSL в каком-то расширяемом языке (например, взять для этого Julia). Даётся критика требований визуальности, высказываются сомнения в reuse онтологических моделей людьми и осмысленность их подготовки для использования кремниевыми мозгами. И указывается, что вероятностные типы и коннективизм тоже нужно включать в рассмотрение. В тексте предлагаются работы для todo list и приводится много разных ссылок. Незнакомому с онтологической инженерией человеку текст не будет понятен. -- https://ailev.livejournal.com/1485657.html

[но это ж всё философия! нет формул!]
Вот стенфордская энциклопедия философии, как раз статья про Type Theory. Вся из формул состоит: https://plato.stanford.edu/entries/type-theory/. то, что мне нужно — тоже ни разу не философия. И пруверы у онтологов — самый распространённый инструментарий. Только онтологи задаются вопросом, какие объекты в мире они моделируют, а математикам это пофиг. Так что это математика+ ))) Онтологика. )))

Вот пример того, что заботит онтологов: https://www.cyc.com/wp-content/uploads/2015/04/AAAI-SharmaA.1646.pdf

Cognitive systems must reason with large bodies of general knowledge to perform complex tasks in the real world. However, due to the intractability of reasoning in large, expressive knowledge bases (KBs), many AI systems have limited reasoning capabilities. Successful cognitive systems have used a variety of machine learning and axiom selection methods to improve inference. In this paper, we describe a search heuristic that uses a Monte-Carlo simulation technique to choose inference steps. We test the efficacy of this approach on a very large and expressive commonsense KB, Cyc. Experimental results on hundreds of queries show that this method is highly effective in reducing inference time and improving question- answering (Q/A) performance.

Формулы в статье есть, в количестве ))) И ссылки на литературу типа Bridge, J. P., Holden, S. and Paulson, L. 2014. Machine Learning for first-order Theorem Proving. Journal of Automated Reasoning, 53(2):141–172

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

[а что такое вероятностные типы?]
Ну, теория веороятностей стала логикой. Вот вам короткая ранняя статья на эту тему -- E.T.Jaynes, Probability theory as logic, 1989, 16 страниц -- https://b-ok.cc/book/454548/12202a. А вот более современная классическая книжка: E.T.Jaynes, Probability Theory: The Logic of Science, 2003, 757 страниц --
https://b-ok.cc/book/942315/05fbc7. Другое направление — это probabilistic programming, https://arxiv.org/abs/1809.10756. Языков на эту тему уже чёртова туча (в частности, реализованных как DSL, в последнее время чаще всего на Julia): https://en.wikipedia.org/wiki/Probabilistic_programming [а вот работа по доказательству правильности вероятностных программ -- Formal verification of higher-order probabilistic programs: reasoning about approximation, convergence, Bayesian inference, and optimization, https://dl.acm.org/citation.cfm?doid=3302515.3290351, январь 2019. И ещё наброски
http://users-cs.au.dk/spitters/ProbProg.pdf Faissole, Spitters, "Synthetic topology in Homotopy Type Theory for probabilistic programming"
https://github.com/FFaissole/Valuations/].

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

[это оффтопик, это статистический анализ программ, а у нас тут логика]
Не надо путать вероятностную логику со "статистическим анализом программ", да и речь не идёт о доказательстве правильности программ. Другое дело, что логика -- это одновременно и про:
— правила хороших рассуждений вообще
— конкретный вариант хороших рассуждений
— тесно переплетена с онтологией (ибо рассуждать всегда нужно над чем-то)

И везде есть математика, доказательства, языки программирования, семантики и т.д.

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

[может, это всё в чат по теории категорий? -- https://t.me/ru_catheory]
У нас было множество попыток использовать теорию категорий в качестве аппарата для языка системного моделирования — все закончились ничем. Не приспособлены кролики для лазания ))) Там кстати и в названии "учим и обсуждаем", но не "обсуждаем и применяем" — прикладность всё никак и никак не получается.
То, что в любой формальной системе можно выразить что угодно, это понятно. Вопрос был в том, что это "легкое и простое выражение" что потом позволяет делать? А ничего особенного, как выяснилось. Просто выражать. Ну, просто выражать можно и так, как сейчас выражают — инженеры же искали не теоретическую красоту, а облегчение свой работы. Облегчения не было предъявлено, пути к облегчению работы не были показаны.

[так а что инженеры ищут в новых теориях?]
Речь шла о создании языка системного моделирования. И обсуждался формализм (или отсутствие такового). Было много разных заседаний. Вот тексты, там в ранних много про теорию категорий — но так и не срослось. Цепочка SysMoLan -- https://ailev.livejournal.com/1443879.html. Но есть и ещё одна задача, по факту та же самая -- о предмете курса вычислительного мышления, https://ailev.livejournal.com/1477090.html

[а что мешает инженерам взять Coq, Idris и прочие языки исчисления конструкций?]
Тогда программисты бы это взяли ещё раньше инженеров. Но не берут ))) Язык оказывается социальной проблемой: берут языки за возможность что-то на них делать, а не за математичность, красоту, современность и прочие качества.

Заход на обучение computer science на базе функционального маленького языка не получился: все остальные курсы не получалось надстраивать над знаменитым SICP, обучение дальше шло по факту с нуля. Прикладная польза была ноль, хотя курс сам легендарный. Для Coq ведь будет то же самое.

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

[вы ходите увидеть язык на все случаи жизни? так универсальные языки универсально неудобны. Инженерам нужны DSL, собранные конкретно для них. И собирайте эти DSL хоть на машине Тьюринга]
Под каждым DSL своя онтология. И мы возвращаемся к проблеме типов. DSL — это domain-specific language. Domain — это предметная область, набор предметов. Что попадает в эти предметы, и как эти предметы описывать — онтологический вопрос. Дальше вопрос не в математической мощности, а в вычислимости, удобстве написания и т.д.

Про машины Тьюринга развлекитесь: https://arxiv.org/abs/1611.02854. Вы ещё дифференцируемые типы не обсуждаете? Пора бы уже. Оптимумы для типов будете искать )))

[так инженеру по требованиям, инженеру-архитектору, инженеру по испытаниям нужны разные языки, они по-разному описывают систему. Так?]
Нет, я не согласен с таким различением — и ровно потому, что вопрос ставится онтологически. Целевой системой и у инженера по требованиям, и у инженера-архитектора, и у конструктора, и у инженера по испытаниям является работающая установка-в-железе (или программа в тот момент, когда она на рабочих серверах и на неё передано управление), в тот момент, когда они наносят непоправимую пользу своей работой. Описание (документирование) происходит и потребностей, и требований, и архитектуры, и планов испытаний, и результатов испытаний. Ключевое требование — чтобы они отражали реальность (онтологичность, моделирование мира, а не просто запись всяких фантазий), а не были просто упражнением в формализации.

Вот это моделирование мира инженерами выполняется:
— в программировании in-the-small (обычно один человек решающий как бы задачку олимпиадного программирования) типами языков программирования, у кого это Julia, у кого-то Haskell, у кого-то Coq (хи-хи), но чаще всего это Java и ООП в полном расцвете сил.
— в программировании in-the-large (много софтов, работающих над какими-то общими данными на разных серверах) некоторой системой типов, наваянной либо над трипл-стором с запросами на FOL, либо над реляционной базой данных, где жужжит реляционная алгебра
— а ещё есть много-много обработки данных, где явной работы с типами нет, а есть Excel-таблицы и всякие запрограммированные на них формулы, работа с типами ведётся тем самым "в уме", а типы представимы в ER-модельке, выраженной набором табличек (но это ни разу не реляционная база данных, и там никакой алгебры, всё руками и не нормализовано).

Вот мой вопрос начальный как раз к тому, что довольно много литературы во отражению мира в реляционных базах данных (равно как работ по критике табличных представлений для подобной работы), чуток меньше литературы про отражение мира во всяких нереляционных моделях данных, например трипл-сторах (семантик веб, как оно называлось — и FOL там была наше всё). Но и там случилась засада, хорошо описанная в https://justy-tylor.livejournal.com/171175.html. Сейчас растёт литература по моделированию мира во всяких NoSQL моделях данных.

А вот литературы по отражению мира в системах типов, развивающихся в "просто языках программирования" нет. Так что там делают всё более и более хитрые модели данных, но неведомо, как их использовать для моделирования задач. Известно же, что в DDD для предметов предметной области (domain-driven design, слово domain то же, что в DSL, и слово "предметы" в "предметной области" я неслучайно употребил вместо привычного "объекта") должны существать какие-то объекты в программе. И эти объекты обычно выражают системой типов. И вот это место сразу становится мутным — какие типы брать, и что ими выражать в мире полностью отдаётся на "опыт и смекалку". Базы данных проектируют хоть как-то, этому специально учат, а вот модели данных в программах почему-то не проектируют — весь акцент идёт на алгоритмику, а не моделирование данных.

Это и был мой начальный вопрос: вот изобрели новую систему типов, всунули её в какой-то язык программирования — но объяснили, что даёт эта система типов для улучшения моделирования данных, для улучшения описания мира? Или это просто выпендрёж из серии "у меня ещё про типы столько разных интересных идей, и ещё столько разной недоиспользованной математики осталось"? (я надеюсь, что достаточно выразительно сформулировал наезд )))

Мой вьюнош как-то пришёл с одного из первых своих уроков физики, и сказал, что физика трудней математики: в математике можно писать что угодно, если не нарушаешь простые правила, а вот в физике нужно всегда проверять экспериментами, соответствует ли это "что угодно" миру за окошком. И математику нужно знать в полном объёме плюс добавить сюда знание мира за окошком, чтобы не фантазировать в своих формульных выкладках. Вот я примерно то же самое спрашиваю про системы типов в языках программирования: пофиг, что там крутая математика — но как в этих типах мир выражать, чтобы ошибок потом поменьше было? Например, в ООП что для одного проекта объект, то для другого атрибут, и наборот (как печально сформулировал консорциум по моделированию данных EPISTLE в конце 20 века). Поэтому для инженерных данных ООП не подходит, ибо страшная головная боль объединять данные разных проектов — в том числе проектов инженерии требований, инженерии системной архитектуры, конструирования (когда на САПР работают и строят трёхмерные модели деталей, проверяя их прочность), испытаний. Если система большая, типа Боинга или атомной станции, то с ООП просто головная боль. Поэтому объектные-из-ООП базы данных не взлетели вообще никогда.

И после того, как объектные-из-ООП базы данных не взлетели по причине неадекватности представления мира для многих проектов (и тем самым для обработки одних и тех же данных многими алгоритмами из разных проектов), я задаю вопрос: а с современными системами типов что на эту тему? Почему не делают базы данных с зависимыми типами? Потому что это полный отстой в проектировании работы разных алгоритмов из разных проектов над одними и теми же данными — ибо есть какие-то аналоги тех же проблем, что и с системой типов из ООП? (надеюсь, и тут наезд достаточно жирно сформулирован, чтобы ожидать на него содержательный ответ)))

[так вы занимаетесь эдакого рода физикой?]
Даже точнее: онтологию традиционно относили к метафизике, а не физике ("над физикой") )))

Хотя я больше занимаюсь эпистемологией — вопросом о том, как я эту онтологию познаю/выучиваю из мира )))

[ну вот поглядите на CQL -- categorical query language, https://www.categoricaldata.net/]
О, это интересно. Про моделирование данных меж тем ничего не сказано, кроме того что вроде как можно отследить преобразования в разных пайплайнах — что откуда пришло и куда ушло.

У меня вообще впечатление, что все "математические" работы идут из постановки задачи programming/modelling-in-the-small. То есть один человек сидит и пишет программку на 200 строк, кучерявые данные не нужны, зависимостей от программ других людей минимум, всё внимание алгоритму и правильности в пределах этих 200 строк. Умножьте даже на порядок или два, это всё равно in the small — один человек=одна картина мира.

Мои вопросы главным образом про поддержку работы in the lagre, когда множество проектных групп делают разные куски системы, исходя из своих разных картин мира, а потом эти куски системы ухитряются совместно работать — ибо они договорились, как совмещать эти разные картины мира/онтики в рамках какой-то одной онтологии.

https://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small

[для сохранения композициональности (когда можно в лоб составлять систему из мелких кусочков) и городится весь теоркатегорный огород!]
Вот не факт, ибо есть мир, есть я, есть они и есть описание мира моё и их — и композициональность как она тут понимается это больше про описание мира без мира, меня и их. Математическая композициональность. Это тоже нужно, да, но дальше хорошо бы показать, как этим пользоваться, тот самый domain modeling в мультипроектной команде, когда они складывают свои описания мира.

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

Ещё есть expression problem — http://en.wikipedia.org/wiki/Expression_problem (и Julia решает её через multiple dispatch, там типы добавляются без необходимости что-то перекомпилировать в старом коде).

То есть заход на эксперименты в in the small хорош, но его недостаточно. Мышление коллективно, программирование/моделирование/онтологизирование тоже коллективно и суть одно.

[ну, мы ещё не разобрались, как записывать всё зависимыми типами, у нас только исследования]
Мой вопрос был главным образом не про "как", а про "зачем" ))) То, что до in the large не добрались, так это часть моего вопроса: по принципиальным сображениям, то есть невозможно до этого будет добраться, ибо работать не будет (как не заработали трипл-сторы и объектные базы данных), или наоборот, после окончания экспериментов вдруг все проблемы будут решены и это станет возможным.

[так инженерам что, нужен для перевода с двух их DSL какой-то третий язык?]
Я вот как раз сразу про этот третий язык — какой он должен быть? ))) Ибо после этого сразу появляется идея, что можно было бы сразу выучить его, если уж на него всё можно перевести с других языков. Он ведь самый универсальный. Собственно, нужда в общей картине мира возникает только в момент встречи двух разных языков и понимании, что начиная с третьего языка уже выгодно иметь какой-нибудь "рабочий английский" в проекте. Когда встречаются китаец, малазиец и испанец, то в этой компании все говорят по-английски, хотя англичан среди них нет ))) Вот вопрос сразу к "английскому для моделирования данных": каким он должен быть? Удовлетворительного ответа на этот вопрос нет.

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

[ну, у нас люди идут по пути создания своей математики со своими основаниями математики. И в гомотопических типах это даже более правда, чем в зависимых типах]
Моделировать не "как в математике". Физики моделируют "как в физике", напрямую используя математику. И в математике есть даже мнения, что математика интенсивно развивалась в 20 веке, именно обслуживая запросы физиков.

У меня запрос похож на запрос физиков к математике. Только я не физик, а разработчики типов в языках программирования не математики. )))

[а что там с экстенсиональным/интенсиональным?]
На эту тему идёт вечная дискуссия. В 4D экстенсиональной онтологии принято считать, что вся система тамошних типов идёт от того факта, что это типизация объектов из реального физического мира (то есть это объекты, занимающие место в пространстве-времени). Если объекты занимают одно и то же место в пространстве-времени, то это один и тот же объект. Например, "Анатолий Левенчук" и "интенсивно цокающий по клавишам субъект" прямо сейчас занимают одно и то же место в пространстве (а "прямо сейчас" указывает ещё и на время). Значит прямо сейчас это один и тот же объект. Внешнее определение через пространство-время — экстенсинональное, а extent это (со времён Декарта) протяжённость в пространстве-времени, то что задаёт наличие объекта в этом мире. Всё остальное — это работа со множествами этих существующих в мире объектов. Множество, понятно, уже не существует в мире, это другой объект.

Ну, и это всё постоянно обсуждается, ибо не все онтологи согласны считать 4D представления о мире чем-то важным. А другие говорят, что тогда им немедленно попрёт фишка фантазировать о мире, плюс появляются неприятные вопросы про то, каков мир в момент времени между 3D его срезами )))

[так у нас математика в типах, в чистой отвязке от физики!]
Ну вот не так. У меня ж полно друзей с мехмата, и он недаром называется "механико-математический" — связь с физикой там предполагается! Вообще, эта привязка к миру или отвязка от мира есть и в самой математике, даже если отползти подальше от физики как таковой. Поглядите текст М.Атья "Математика в двадцатом веке", http://www.mccme.ru/free-books/matpros/i8005024.pdf.zip — он там про алгебраическую ветвь математики, "фон-нейман-компьютерную" и геометрическую ветвь, с приветом физикам, пространству и deep learning.

Можно ещё пообсуждать: когда я пишу про математику и про приготовление зелёного чая — это я по-русски пишу, или таки использую два языка "чтобы удобно было"? Или это DSL на базе русского хост-языка? )))

[если нужен таки третий язык, то это будет линейщина-моноидальщина, выраженная n-категорным языком. Если совсем попросту, то мультимодальная линейщина]
Ну вот ткните меня в книжку типа https://pragprog.com/book/swdddf/domain-modeling-made-functional для этого, или места, где такое обсуждают сейчас для этой мультимодальной линейщины. [7 скетчей, наверное, самое близкое]

[Но задачи будет решать не проще, если всё просто переписать в более общий язык]
Верное замечание. В deep learning в последнее время там воздерживаются от публикации работ с обобщениями или переформулированием в другие формализмы, если это не двигает как-то SoTA. Теоркатегорщикам можно заказывать кружку "your model is a special case of my model", это недорого: https://www.cafepress.com/mf/34058049/special-case_mugs

[так а CQL чем не подходит? язык запросов к базе данных на теоркатегорных основаниях!]
Там в статьях ссылка на categorical.info перенаправляется на https://conexus.ai/ — мотенизация CQL идёт полным ходом.

сonexus offers support for open-source CQL, support for data integration projects using CQL, and sells a proprietary extension of CQL that scales the open-source version along three dimensions:
- Visualization and programmer productivity
- Data size beyond a single in-memory node
- Artificial intelligence capabilities beyond simple equational reasoning

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

Вот критика этих табличных и реляционных представлений (BORO Book, http://borosolutions.net/sites/default/files/Business%20Objects%20-%20Re-Engineering%20for%20Re-Use%20%282nd%20Ed%20-%20watermarked%20draft%20-%2020050531%29.pdf#page=1&zoom=auto,-22,848), и это же пример IMHO лучшей онтологической книжки по моделированию данных (про концептуальное моделирование, а не про физическую реализацию, языки запросов, скорость работы и т.д. про foundational ontology там нет, там только про мир и его модели и как это должно отображаться разными типами в upper ontology).

Печаль момента в том, что предложенная концептуальная модель кладётся далее в триплы — а это тупик.
* * *
Окончание текста в https://ailev.livejournal.com/1486407.html

Обсуждение в чате блога -- https://t.me/ailev_blog_discussion/402, в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216100232112621, в новом чате телеграмма про типы языков программирования (уже все типы, а не только depended), буквально с самого начала чата -- https://t.me/typeslife
Thursday, August 22nd, 2019
7:07 pm
Защита эссе "Системное мышление в развитии детского сада"
Опубликовано видео защиты эссе по системному мышлению Лии Султановой (https://www.facebook.com/liya.sultanova), директора детского сада Монтессори -- https://www.youtube.com/watch?v=AeXV9mueoug.

Что важно, так это не просто эссе по "описанию" детского садика Монтессори в системном языке. Это по факту отчёт о преобразованиях, которые были сделаны в детском садике с использованием системного мышления.

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

Людям, занимающимся образованием, смотреть обязательно.

Обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216092752485635 и https://www.facebook.com/ailevenchuk/posts/10216092752485635
Sunday, August 18th, 2019
8:52 pm
Типы языков программирования как foundational ontology
Вот тут сравнивают OP (object paradigm) из BORO book и ORM (object-role model) как пример 4D против 3D онтологии, 2012 год -- https://arxiv.org/abs/1207.2619. И делают вывод, что 4D выигрывает во всём, кроме двух вещей:
-- нужно серьёзно поломать мозг (ну, как для ньютоновской физики, где палец давит в стол, а стол давит в палец, по сравнению с аристотелевской, где палец давит в стол, а стол в палец давить никак не может). Ну, это задача образования. Люди обучаемы, в том числе люди обучаемы state-of-the-art 4D онтологии, при этом одной хорошей онтологии не хватит никогда (это ж не физика!), учится этому придётся много, и нужно сразу будет учить онтологическому кругозору.
-- отсутствие нормальной визуальной нотации. При этом признаётся, что чаще всего в 3D онтологии никакой онтологии времени нет, а есть "просто типы" из foundational ontology. И можно просто нарисовать 4D объекты и отношения в рамках "просто типов" из foundational ontology. Но это кривовато. Я согласен, что это кривовато, но отлично работает! Какой-нибудь IFC в BIM именно так и устроен -- абстрактная структура для изображения объектов, отношений, атрибутов, презентаций и т.д., но потом на ней реализуется ad hoc модель предметной области, от "презентации онтологии" переходим к собственно онтологии, от foundational к upper, от "моделирования мира" к "каков мир" -- с молчаливой улыбкой в ответ на вопрос, что структура мира существенно зависит от тех выборов, которые мы сделали в момент, когда выбирали средства для моделирования этого мира. Вот с чем я не согласен, так это с тем, что удобная нотация для foundational ontology должна быть визуальной. Это я подробно писал в книжке "Визуальное мышление. Доклад о том, почему им нельзя обольщаться" (https://ridero.ru/books/vizualnoe_myshlenie/).

В языках программирования ровно оно: foundational ontology без каких-то внятных онтологических посылок. Типы, и всё. Холст, на котором рисовать, никаких предположений, что там будет рисоваться, какой мир. Никаких замечаний про моделирование мира не делается, поэтому 4D или 3D вопрос не поднимается. Можно пообсуждать, где разница между
-- upper ontology (верхнеуровневая онтология: из чего же состоит мир -- в том числе 3D/endurantiosm и 4D/perdurantism оттуда)
-- foundational ontology (онтология выразительных средств, язык разговора об онтологии, innate priors о моделируемом мире -- выбранная теория понятий, https://plato.stanford.edu/entries/concepts/ включая де-факто победившую в онтологии theory theory https://www.iep.utm.edu/th-th-co/ и далее проход в типизацию -- различие между типами и конкретностями, и дальше ход на теорию типов и языки программирования).

Обо всём этом см. мои рассуждения того же 2012 года "Понятия и категории: в мозгу, софте, справочных данных", https://ailev.livejournal.com/1007293.html. Не очень много изменилось с тех пор, разве что стал понятен де-факто тупик с триплами как универсальным представлением, и появилось понимание статистической природы языка и отнесения к типам в связи с развитием deep learning, плюс самые разные варианты смешения символьного и коннекционистского вывода. Ибо будущее в этом стыке, и нужно это будущее учитывать уже сегодня. Вот, например, какие интересные проекты входят на поверхность: https://www.ai21.com/sense-bert (комментарий про эту попытку внести побольше семантики в BERT см. в https://medium.com/syncedreview/israeli-ai-research-company-led-by-stanford-professor-and-mobileeye-ceo-introduces-model-to-solve-747acaad8357).

Вот нужно с этим как-то доразобраться, пункты для todo list:
-- теория типов и современные языки программирования как основа для foundational ontology в оппозицию теории баз данных и моделей данных. Нужно как-то соединить кресты металлические с крестами католическими (foundational ontology от upper ontology примерно так и соединены). И в эту точку ещё и про статистическое отнесение к типам, и про выучивание типов что-то понять. На эту тему только что прошло обсуждение в чате Julia, и там дали ссылку на сообщество, обсуждающее типы в языках программирования: https://t.me/joinchat/Ai4h2D9SWO8GfISyv-CHsQ
-- предложение нормального текстового моделирования онтологии на языке с современными типами (Julia с онтологическим DSL тут вполне пойдёт, просто сделать нужные макросы. И даже если речь идёт о статистически определяемых типах, это тоже можно отмоделировать, почему бы и нет).

А ещё нужно ответить на "социальный вопрос": будут ли пользоваться аналогом "стандартной библиотеки" или "прикладных пакетов" в языках программирования в случае онтологий? Или каждый раз на коленке писать собственный онтологический код, выполнять кривое онтологическое моделирование? В проектах интеграции жизненного цикла предпочитают каждый раз моделировать с нуля, чужими справочными данными не пользуется никто и никогда. Вопрос, по большому счёту, тот же, что и для языков программирования и фреймворков, только в этих языках нужны прежде всего операции, а тут речь идёт о моделировании мира. И операции люди предпочитают брать из фреймворков, а вот модели мира (над которыми потом делать свои операции) -- нет. Модели мира каждый делает сам, в зависимости от своих потребностей. С чужими моделями мира (а хоть и "популярными") в свои проекты не принимают. Но без какой-то связной модели мира плохо. Всё-таки прикладные системы делать хорошо на основе предобученных моделей, просто подстройкой к прикладной предметной области, как описано в https://ailev.livejournal.com/1485511.html. Какой-то knowledge graph это как раз из этой области, мы ж о его создании говорим? О языке его представления.

При этом текущий стандарт текстовых нотаций для онтологии/knowledge graph -- или OWL, или язык логики первого порядка (Common Logic aka ISO/IEC24707:2018), или язык представления знаний с логикой "полуторного порядка" типа CycL (https://en.wikipedia.org/wiki/CycL). Ну, или есть ещё языки манипулирования данных (не запросов! запросы ведь ничего в базе данных не меняют, схему базы данных не строят) самых разных баз данных -- там другой заход, очень простые foundational ontology, никакого сравнения с системами типов из языков программирования. Всё, что нужно сделать -- это предложить какую-то удобную нотацию для простого варианта чего-то похожего на онтологию из BORO book или HQDM, привязанную к системному подходу. Это в сочетании с Julia и пакетами инженерного моделирования и будет SysMoLan (https://ailev.livejournal.com/1443879.html). А теоретическая часть ляжет в основу курса вычислительного мышления -- https://ailev.livejournal.com/1477090.html

И всё это ни разу не должно быть визуальное. Если речь идёт о программировании, моделировании, онтологизировании, симуляции, обучении и т.д. -- всё только текстовое. Всё визуальное -- это первые 15 минут поиграться фломастером на флипчарте, и даже без какой-то нотации. Просто в пространстве раскидать какие-то идеи для будущих концептов, чтобы было удобно показывать на них пальцем, и всё. Можно и слова раскидать по флипчарту, кружочки и квадратики раскидывают только потому, что слов-имён для новых концептов ещё нет, просто место их обозначают. Но таки потом долго и плодотворно моделировать нужно только в тексте, с использованием онтологической IDE, студии моделирования-онтологизирования-программирования.

И да, социологические вопросы интересны только тогда, когда с этим knowledge graph работают люди -- в тех же проектах интеграции данных жизненного цикла. А если с ним работают алгоритмы AI, то всё ОК. Для них таблетки знаний жуются долго, но всё-таки прожёвываются. Это не непреодолимое препятствие, речь тут в конечном итоге идёт не о людях. Люди тоже будут участвовать, но их нужно очень мало, хотя и очень высокой квалификации. Остальное сделают кремниевые мозги.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216065238597805
Friday, August 16th, 2019
7:32 pm
Предобучи, потом подстрой/pretrain then finetune
Текущий тренд в работе с естественным языком -- это использование языковых моделей. Берётся огромная пустая нейронная сетка, и ей скармливается огромный (gargantuan) корпус текстов на всех доступных языках. В этих текстах отражены какие-то свойства языков в целом (кормят текстами отнюдь не только одного языка), а также свойства мира (ибо все эти тексты о чём-то в мире) -- сетка выучивает что-то общее про языки и мир. Это называется pretrain, предобучение. И занимает или огромное время, или огромные деньги (рекорд сегодня -- это обучение языковой модели BERT всего за 53 минуты -- но на 1472 GPU V100, это 92 компьютера DGX-2H ценой $399тыс., то есть там только аппаратуры для этого почти часового счёта на почти $40млн, https://devblogs.nvidia.com/training-bert-with-gpus/). Итого: pretrain даёт какие-то знания о языке и мире, но фишка в том, что такая сетка не может при этом решать никаких прикладных задач. Про задачи и конкретные предметные области эта сетка ничего не знает.

Так что потом идёт finetune, подстройка -- берётся эта безумно дорогая language model и очень быстро и дёшево доучивается решать одну или даже десять конкретных прикладных задач. Фишка в том, что дорогое предобучение делается один раз, а потом подстройка делается легко и быстро каждый раз. За последний год такой подход предобучения+настройки стал мейнстримом в deep learning (см., например, Pretrain then Finetune: A New Paradigm for NLP -- https://www.mihaileric.com/posts/nlp-trends-acl-2019/).

Всегда говорил, что deep learning даёт хороший язык для разговора об обучении, хорошие модельки -- лучше, чем у профессиональных педагогов. Так что этот мейнстрим глубокого обучения позволяет относительно просто рассказать, чем же мы занимаемся в Школе системного менеджмента.

Мы в ШСМ занимаемся предобучением, то есть формируем самые общие фундаментальные знания о мире (язык-то все уже знают, именно языковой модели учить не нужно, но вот надёжной и компактной модели мира, мышления и себя у большинства людей). Так что мы предобучаем мокрую нейросетку наших курсантов. При этом мы ещё и хорошо структурируем наш материал, что в мире deep learning только-только собираются делать с использованием knowledge graphs или других символьных методов.

А потом получение прикладных компетенций на базе нашего предобучения -- это лёгкая и быстрая подстройка, и результат этой подстройки будет state-of-the-art, и подстройка эта может легко делаться в самых разных прикладных областях, для решения самых разных задач. Наши курсанты продолжают учиться и работать, но после нашего предобучения дальше идёт не столько тяжёлое "обучение", сколько облегчённая подстройка.

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

А подстройка? Подстройку могут дать все тысячи и тысячи прикладных учебных заведений. Это дёшево, это быстро, это понятно. Но они не могут обеспечить предобучения. Они могут обеспечить только подстройку. А за предобучением -- это к нам.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216049880013850
Tuesday, August 13th, 2019
12:27 am
lytdybr
Сплошные августовские юбилеи -- 3 августа 2017 ровно два года, как я купил полуспортивный самокат (https://ailev.livejournal.com/1363871.html), и он до сих пор не развалился. Городские же самокаты разваливались до этого ежегодно. 4 августа исполнилось 25 лет http://libertarium.ru -- вода в аквариуме, свобода в либертариуме! Сайт вполне жив все 25 лет, работает и сегодня. 10 августа исполнилось три года, как я узнал про существование кизомбы и пошёл ей учиться(https://ailev.livejournal.com/1285622.html), а последний раз танцевал кизомбу вчера.

Вьюнош в очередной раз сбрил бороду и пошёл в летнюю физическую школу МФТИ рядом с домом. Я считаю это бесполезным делом, но для него это развлечение. На этих курсах его даже смогли удивить: человек бежит со скоростью 2м/сек и натыкается ногой на мяч. С какой скоростью полетит мяч? Правильный ответ: 8м/сек.

Я не очень понимаю, какой можно было бы дать силовикам асимметричный ответ. Пока идёт сценарий ненасильственного протеста: "бьют по правой щеке, подставь левую" -- одного силовики показательно бьют, десяток митингующих, стоящих рядом, не вмешивается, снимает всё на видео и постит в соцсетях. Все довольны (кроме того, кого побили): безнаказанность силовиков отрекламирована, беззащитность избиваемых отрекламирована, невмешательство большинства населения в избиения силовиками отрекламирована, снимающие фото и видео вроде как "что-то полезное сделали". Эти избиения, съёмы кандидатов с выборов и т.д. могут продолжаться при отсутствии суда вечно -- если не будет какого-то асимметричного высокотехнологичного ответа от гражданского общества. Вот, например, мод Tesla S, замечающего за собой слежку: https://www.wired.com/story/tesla-surveillance-detection-scout/. Это не технология слежки, это технология обнаружения слежки! Но это всё про глаза и уши, а асимметричность должна быть как-то связана с руками и ногами: без выхода в физический мир никакого ответа не получится. "А Васька слушает, да ест" -- это ж как раз про невыход в физический мир. Не, я всё знаю про суд Линча, и что он нехорош. Но когда все официальные суды в стране становятся судами Линча -- как быть?! Может, асимметричный ответ был бы в создании теневого/оппозиционного уголовного суда прежде всего. Ну, и института теневых/оппозиционных приставов, без силы безнаказанную силу не остановишь. Но применение силы должно быть правовым, вот настоящие оппозиционные (не сомневаюсь, что с настоящими юристами в них, чем они хуже липовых судей в официальных судах?!), а не фейковые басманные суды это и должны обеспечить. Ибо силовой ответ вместо "мирного протеста" -- это симметричный ответ. А нужен ответ асимметричный, хотя и выходящий в конечном итоге в физический мир. Как только пойму, какой тут ответ может быть работоспособным, начну действовать. Пока же не вижу, какие мои действия были бы глобально полезней того, что я сейчас делаю -- учу людей думать головой.

А вообще-то мы живём в интересные времена, так что жизнь (в том числе и политическая, в том числе и полицейская) будет стремительно меняться. Так, Facebook неожиданно подошёл очень близко к человеческим результатам в новом тесте понимания естественного языка -- https://super.gluebenchmark.com/leaderboard/ (RoBERTa 84.6%, у людей 89.9% -- а ведь совсем недавно BERT++ был там всего на 71.5%, скакнули сразу на 15%). Всё больше и больше голосов про "застой", "отсутствие прорывов" -- ничего подобного, всё только ускоряется, и главная фишка тут в том, что deep learning просто пока затмевает все остальные исследования. Я ожидаю реальных прорывов сейчас от гибридных архитектур (графы знаний+нейро, эволюционные алгоритмы плюс нейро и плюс логика, и т.д.). Doug Lenat, например, продолжает линию ускорения вывода на больших графах знаний статистическими методами, при этом хвастается тем, что от по факту финансирования госсиловиками перешёл в последнее время к нормальному финансированию коммерческими компаниями и теперь CYC прибыльная компания -- https://www.forbes.com/sites/cognitiveworld/2019/07/03/what-ai-can-learn-from-romeo--juliet/, https://www.cyc.com/publications/. А вот китайский чип, гибридный для нейронных сетей "обычной сегодня" и спайковой архитектуры -- https://medium.com/syncedreview/nature-cover-story-chinese-teams-tianjic-chip-bridges-machine-learning-and-neuroscience-in-f1c3e8a03113. А вот вышла в opensource EvoGrad, lightweight library for gradient-based evolution от Uber -- https://eng.uber.com/evograd/. В итоге мы доживём до киберпанка гораздо быстрее, чем можно себе представить. И никакое госрегулирование не поможет (недаром все книжки про киберпанк сводятся к тому, что жизнь идёт мимо госрегулирования). В мире киберпанка туповатым космонавтам, разгоняющим демонстрации и садистски "только выполняющим приказ", места может уже и не быть, равно как и демонстрациям. А что будет? Да много чего будет: ключевой характеристикой в эволюции (а это именно она) является рост видового разнообразия со временем. Так что много чего будет разного, огромное количество разных ниш, огромное количество жизненных укладов. Кембрийский взрыв, ага. Во всех областях жизни.
Monday, August 12th, 2019
9:41 pm
Дело в шляпе? Нет, в шляпе как раз не дело. Дело в ролях.
Оказывается, не все понимают, что "шляпы" -- это традиционное обсуждение ролей в английском на уровне сюсюканья (то есть абсолютно бытовом). Ничего оригинального или научного, чистая бытовая кулибинщина с ролями, наколенное творчество любого англоговорящего человека, проходящего мимо какой-то профессии, "публицистика без последствий", не более.

Вот вам гугль запрос на шляпы для учителя (с этих учительских шляп, собственно, всё и началось) -- https://www.google.com/search?q=many+hats+of+a+teacher

Кто обожает картинки, пройдите там по ссылке "картинки", их там сотни. Кто предпочитает тексты, почитайте тексты, их тоже сотни. И по любой другой профессии будет то же самое, не только по учительской -- шляпы в английском абсолютно традиционны при подобных обсуждениях. Вот, например, для менеджера -- https://www.google.com/search?q=many+hats+of+a+manager (и там попутно кого только нет, даже множество шляп юриста).

Я повторю свой тезис, что обсуждения лучше бы делать профессиональными. Если хочется пообсуждать проектные роли учителя, то придётся обсуждать роли, интересы, предпочтения, намерения, практики/деятельности -- полный набор понятий, задаваемых схемой (схемой, а не картинкой).

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


Игры со счётными палочками в первом классе переходят в изучение арифметики как минимум потому, что учителя арифметики знают и про четыре арифметических действия, умеют делить и умножать в столбик. Шляпы в изучение сначала ролей вообще, а потом и театральной метафоры для ролей людей не переходят, так и остаются шляпами, "счётными палочками" -- люди, которые в этой терминологии пишут, в ролях особо ведь не разбираются, они только "мотивируют" окружающих поразбираться. Это всё публицистика, то есть развлекательное чтиво, не требующее каких-то последующих действий или хотя бы дополнительного изучения вопроса. Но мне было бы интересно поглядеть на какие-то серьёзные материалы по проектным ролям в образовательных проектах. Я писал про это в https://www.facebook.com/groups/blended.learning.russia/permalink/2389749841267551/ (и давал ещё несколько ссылок в https://ailev.livejournal.com/1484368.html). Но тогда я не знал, что многие читатели не представляют, обыденность и банальность этих текстов со "шляпами учителя" (почему и предлагаю в этом посте пройти по ссылке гугля и ознакомиться с этими сотнями текстов и картинок).

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

Вот первые две подглавки третьей главы моего учебника "Системное мышление 2019" ((https://ridero.ru/books/sistemnoe_myshlenie/)), она называется как раз "Роли". Текст не простой, но зато он позволяет с этими ролями разобраться подробней. Ибо мышление про роли (функциональные объекты) и их поведение (функции) у большинства людей очень мутное, хотя оно крайне необходимо для нормальной инженерии и нормального менеджмента.
* * *
3. Роли
Роли и действия
Системное мышление рассматривает системы как имеющие какое-то назначение в своём окружении, то есть играющие какую-то внешнюю роль. Молоток играет роль гвоздезабивального устройства. Эту роль может играть камень, может играть микроскоп. Можно назвать систему, которая играет роль забивателя гвоздей молотком — по её первичному назначению. Назначение — это поведение системы в роли, действие. Действие — забивание гвоздей. Роль системы — забивать гвозди. Система в роли — забивальщик гвоздей. Всё это об одном и том же, разве что иногда нам нужно указать на действие (куда может входить не только сама система в роли выполнителя действия, но и сопутствующие предметы — гвозди, доска, плотник), а иногда на главный в этом действии объект-в-роли, систему. И чаще всего (увы, но это так) при этом используется «аристотелевская физика», в роли забивальщика гвоздя будет «активный объект» — молоток (или любой предмет, назначенный на роль молотка), при игнорировании в этом взаимодействии действий всех остальных предметов. Помним аристотелевскую физику? Когда палец давит на стол, но стол не давит на палец? Роли очень часто рассматриваются ровно так: ролевой объект действует на другой ролевой объект, а обратным действием пренебрегают.

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

Одним из примеров такого подхода служит инженерный способ разработки требований «сценарии использования» (use case, но автор Ivar Jacobsen оговаривал, что в шведском языке, на котором он сначала предложил этот способ разработки, вместо слова case использовалось слово «сценарий»). Сценарий — это последовательность действий актёра/актора/actor, то есть активного действующего предмета. Это может быть как человек (и в предлагаемом для описания сценариев использования для описания актёра служит фигурка человека), так и вовсе не человек, и даже неодушевлённый предмет — тот же молоток, который предлагается активным элементом в последовательности действий, складывающихся в пьесу-сценарий. Сценарии использования оказались очень удачны для описания работы/процессов/последовательностей_действий/сценариев/поведения системы и её частей. Этот способ описания стал повсеместным для инженеров, он приводит к построению функциональных/ролевых описаний.

Термин «функция», как мы обсуждали в первом разделе, имеет множество самых разных значений. Очень часто ролевое поведение/действие (поведение для какого-то назначения) называют функцией. Так, могут говорить, что функция молотка — забивание гвоздей.
Эта функция/ролевое поведение/действие ему назначена какими-то людьми, это не сам молоток себе эту функцию назначил. Например, мы можем взять микроскоп и назначить его молотком — забивать им гвозди. Молоток при этом — не более чем роль для микроскопа (или камня, или даже молотка), а поведение в этой роли — забивание гвоздей.

Если выбрана терминология с «функцией», то функция выполняется функциональным объектом (или, что то же самое, ролевое поведение выполняется ролевым объектом, или действие выполняет ролью. Или функциональный объект называется функциональным элементом, при этом игнорируется тот факт, что «элемент» означает что-то неразделимое дальше на части. Слова термины важны и не важны!).
Приём мышления тут состоит в том, что для каждой роли (функционального объекта) предусмотрено культурно-обусловленное (иногда говорят «нормативное», обусловленное культурными нормами и правилами) поведение. Мышление позволяет использовать в какой-то роли самые разные предметы, и думать о них одинаково. Если функция/действие — забивать гвозди и роль/ролевой объект/функциональный элемент — молоток, то камень, микроскоп, специально сделанный для забивания гвоздей молоток в общем и целом будут делать одно и то же. И совпадение имён ролевого объекта «молоток» и физического объекта «молоток» тут можно считать случайным.

Знания передаются из ситуации в ситуацию в виде норм поведения для ролей, а не норм поведения для разных физических объектов.

Этот приём, когда вещи определяются по их основному назначению/роли/функции, по их ролевому поведению, позволяет существенно экономить мышление. Системы прежде всего рассматриваются как ролевые/функциональные объекты в тот момент времени, когда они выполняют свою роль, то есть готовы и работают, приносят пользу. Например, самолёт как система — это прежде всего ролевой/функциональный объект, который летит, при этом перевозя по воздуху пассажиров и грузы. Назначение самолёта — самому летать. Назначение насоса — насасывать.

Системы именуются обычно по первичному их назначению, то есть по назначаемым им ролям, эти роли и определяют их поведение/действие/функцию. Когда мы именуем микроскоп, то прежде всего имеем в виду то, что он позволяет «мелко смотреть» в тот момент, когда он полностью изготовлен и работает. Если бы мы считали, что микроскопом нужно главным образом что-то колотить (орехи, например, колоть), назвали бы его «колотилка».

Как всегда в языке, самые древние названия имеют неясное происхождение и часто указывают не на роль/функцию, а на форму (молоток, маленький молот — но вот сам молот — это от «молотить», «бить») или что-то другое. Но если мы разрабатываем системы, или хотим понять что-то про системы, то в названии правильно искать не физический объект, представляющий систему, а роль — и указание на действия.

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

Мы можем мыслить о Принце Гамлете, подразумевая что он существует в тот момент, когда его роль играет один из актёров (например, известный артист Василий Пупкин). По Принцу Гамлету в этот момент можно постучать, можно ткнуть в него пальцем, он занимает место в пространстве-времени. А когда Принц Гамлет идёт обедать? Ответ: никогда, ибо обедать идёт Василий Пупкин, а Принц Гамлет во время обеда не существует — он прекращает в этот момент своё существование.

Можно вспомнить, что мы с разными именованиями или прочими неопределённостями по поводу совпадений и различий объектов разбирались в соответствии с предложением Декарта: нужно уходить от определений (прекращать спор о терминах, названиях и т.д.) и обсуждать вопрос, какое место в пространстве занимают обсуждаемые предметы. Роль и играющий её физический объект, конечно, будут занимать одно и то же место в пространстве. При этом ролевой объект может исчезнуть в любой момент, когда его роль закончится — когда физический объект прекращает играть его роль. Физический же объект просто так не уничтожишь — действует закон сохранения материи.

Например, я могу выделить в своей жизни (ролевой по отношению к моей жизни!) объект «моя любимая игрушка» — это плюшевый мишка в период 40 лет назад, игрушечный самолётик в период 30 лет назад и планшетный компьютер сегодня. А в промежутках, может быть, мне было не до игр, и этот ролевой/функциональный объект «моя любимая игрушка» в этот период вовсе не существовал. Физические индивиды, играющие роль функционального объекта «моя любимая игрушка» несколько раз менялись, а вот функция/действие/поведение «участвовать в моих играх» оставалась той же. Моя любимая игрушка в тот момент, когда она существует, вполне занимает место в пространстве — по ней можно постучать, её можно понюхать, о ней можно говорить как о физически существующем предмете. Но, конечно, вы будете стучать и нюхать физические объекты, играющие эту роль в те или иные моменты. Если вы захотите понюхать Принца Гамлета, то вы унюхаете только запах Васи Пупкина, играющего его роль. Или не унюхаете ничего, если Вася Пупкин не будет играть эту роль. Но по факту запах Васи Пупкина и будет запахом Принца Гамлета, как его внешний вид и будет видом Принца Гамлета, как играемая им роль будет последовательностью действий Принца Гамлета.

Зачем нужны ролевые/функциональные объекты? Чтобы отделить выполнение каких-то действий от объектов, выполняющих действия. Действий в мире не так много (можно сравнить число их типов условно с числом глаголов в языке — несколько десятков тысяч), а вот объектов, пригодных для действий (как и существительных, которых в языке сотни тысяч) — огромное разнообразие. Поэтому можно обсуждать деятельность «президента США» и накапливать знания об этой деятельности — независимо от того, кто выполняет эту роль сейчас. Точно так же можно по его роли выделить объект «водяной насос» и деятельность «повышение давления» и дальше использовать или физический насос Муромского завода в этой роли, или водонапорную башню. Рассуждение тут одно и то же про «президента США» и про «водяной насос». Все ролевые/функциональные рассуждения устроены абсолютно одинаково — и про людей, и про животных, и про системы искусственного интеллекта («нежить»), и про совсем уж неживые системы.
Эта одинаковость обсуждений очень удобна. Поэтому система определяется как ролевой/функциональный объект (играющий какую-то роль в своём окружении, выполняющий там функцию/действия/назначенное_поведение), и также как физический (существующий в физическом мире) объект. Если не играет роли (никак себя не ведёт) — не система! Если не существует в физическом мире, то не может играть роль — не система!

* * *
А дальше в этой главе подглавки про людские роли (и шляпы там не упоминаются):
-- Второе поколение системного подхода
-- Театральная метафора
-- Мышление о людях: прежде всего они исполнители ролей
-- Интересы и предпочтения
-- Позиция
-- Лидерство
-- Внешние и внутренние роли/стейкхолдеры
-- Организационные места, оргзвенья
-- Звание и компетенция
-- Сколько всего стейкхолдеров
-- Кто участвовал в последнем совещании?

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216023884603981
Sunday, August 11th, 2019
10:51 am
Системное мышление как санитар леса
Выступил вчера с сообщением "Системное мышление как санитар леса" на прикрацном ДР (прикрацный -- прикладной рациональности, а ДР -- это модный сейчас день рождения с лекциями. Заодно ещё раз поздравляю Пион с днюхой!). Вот слайды: https://yadi.sk/i/WjlkN8Btb6cOuA

Системное мышление хорошо не только тем, что помогает сделать проекты огромной сложности. Системное мышление хорошо тем, что быстро убивает плохие проекты. Вот берёшь системную схему проекта -- и проход по ней как по чеклисту очень часто показывает, что проекта-то и нет. Значит, нужно этот проект немедленно бросать и не поддаваться на уговоры "ну вы придумайте что-нибудь там". Если идея сразу или за пару дней не пришла в голову, то не нужно надеяться на свою гениальность. Идея по оживлению мёртвого проекта и за пару лет может в голову не прийти. Меняйте тогда проект смелее, начинайте следующий. Системное мышление быстро убьёт и его, если он с рождения дохлый. Проекты не люди. Это слабых младенцев нельзя бросать со скалы, как в Спарте. А слабые проекты должны быть убиты, и быстро, чтобы на них не было потрачено много сил, нервов и инвесторских денег. Ну, или вы должны честно сказать, что занимаетесь дохлым проектом в плане любви к зомби и переводите это занятие в план развлечений, и затраты на проект списываете по графе "развлечения". Вдруг вы проектный некромант, у вас хобби такое! Но вы должны хорошо понимать, что такое хобби очень затратно.

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

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216013856793292
Saturday, August 10th, 2019
7:55 pm
Моё образование для образованных в августе
По просьбе модераторов группы "Смешанное обучение" привёл несколько ссылок на свои тексты про роли в образовательном проекте -- https://www.facebook.com/groups/blended.learning.russia/permalink/2389749841267551/. И там в дискуссии много моих ответов на то, как из отечественной дидактики вопрос "чему учим" исчез, остался по факту только вопрос "как учим". И обсуждается роль методолога, который из множества методов выбирает тот state-of-the-art, которому нужно учить, дисциплину для которого делает учёный, а результат работы методолога в форме учебных материалов курса оформляет методист. Всё это ссылки на мои работы прошлых лет, нужно бы этот вопрос с ролями где-то подробней раскрыть -- как я об этом думаю прямо сейчас. Заодно там и много разных других забавных моментов (скажем, я разворачиваю агентность, а мне позиционеров и акторов и психологизмы приписывают в их винегретной смеси -- но у меня-то другое по факту предъявляется, это интерпретация вынуждено винегретная, если у интерпретатора знакомство с акторством, позиционерством и психологией!). А приглашение что-то сказать про роли в сообществе "Смешаное обучение" я получил после высказывания недопустимости обсуждения ролей педагогов на уровне сю-сю (то есть в терминах "шляп", вот тут "инфографика ролей" в современном ужасном стиле, который призван быть лекарством, но по факту болезнь -- https://www.facebook.com/groups/blended.learning.russia/permalink/2386995454876323/. Там в комментах вопрос, не скучно ли мне всё обсуждать профессионально и научно. Вот профессионально-то мне как раз не скучно, в этом фишка! Непрофессионально -- вот такое скучно, когда развлекательный и мотивационный аспект затмевают содержание). Обычно я сюда в блог вытаскиваю комменты из тамошних дискуссий, но не хочу даже этого делать: кому тема оргролей в образовании интересна, идите по ссылкам и читайте. А ещё я запостил в эту группу весёлую картинку про эволюцию образования -- https://www.facebook.com/groups/blended.learning.russia/permalink/2387584294817439/ (и эта картинка была там была расшарена 101 раз и получила 67 лайков за три дня, уж больно чёрный и печальный там юмор).

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

Ещё раз я прошёл наш курс "Телесная инженерия" и три дня из четырёх "Системного фитнеса". очень рад не столько даже своим собственным телесным успехам (их есть), но и успехам в развитии самого курса, чем я довольно активно занимался в последнее время: у обеих групп (это не случайность!) на силовой части курса никто не ойкал, никто не кряхтел от сверхусилий, всё было спокойно и по-будничному. Ура, мысль о "диванном фитнесе" таки удалось донести, причём буквально с первого занятия (хотя были и отклики, что "в чём суть курса до меня дошло только на третий вечер, уж больно непривычно было всё происходящее" -- в коротком курсе). Много обсуждаем отличия курса от других двигательных практик, типа "по сравнению с йогой нет предписанных асан -- любая поза наша асана, при этом всё должно происходить быстро с танцевальными и спортивными скоростями, никаких застываний в неподвижности -- но гибкость должна быть не меньше, а даже больше, и сосредоточение должно быть даже больше, но без ухода внутрь себя, ибо в танце и спорте нужно продолжать воспринимать не только внутренний мир, но и внешний быстроменяющийся мир во всей его полноте", "силовые тренировки -- но нам нужна гибкость, не хуже, чем на йоге, и скорость. Но да, сила вся должна остаться!"). Мы в ближайшее время выпустим апдейт презентации и чеклисты, активно над ними работаем. Вот основной алгоритм курса (из презентации):
1. Проявление проблем: поднятие чувствительности/диагностика неразличимости усилий и обмякания. Принцип радара.
2. Решение проблем: разнообразие приёмов поиска обмякания и запоминание дообмяканий.
3. Добавление функциональности: осознанное включение лент чистого натяга и чистой скрутки в статике (амплитуды)
4. Добавление функциональности: осознанное управление лентами при смене позы (скорость) и под собственный вес (сила)

Моделирование социальных танцев существенно продвинулось, смотрите последние тексты в https://vk.com/buffdance. Оказалось, что в танцах выделяем биомеханику ("дыхание" и телесные формы/стилистику) и лексику. Эти модели проверяем на практике, они открывают путь к обучению социальным танцам впятеро-вшестеро более быстрое, чем это происходит сегодня.

Обсуждаем идею клубных абонементов в ШСМ -- примерно так же, как в фитнес-клубах или школах танцев, где образование заведомо многолетнее, но нельзя выделить конкретных "программ". Эта "клубность" очень хорошо соответствует идее continuous learning -- берёшь клубную карту, и становишься членом клуба, то есть имеешь право посещать без дополнительных плат все курсы Школы, включая многократное их перепрохождение. И чем больше при этом учишься, тем выгоднее становится иметь такую карту. А ещё помним, что у древних греков "досуг" -- это было "время для самосовершенствования". Досуг хорошо посвящать тому, что приходить в клуб -- и там учиться!

UPDATE: обсуждение ВКонтакте -- https://vk.com/wall2449939_2349, обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216009314959749, про "эволюцию образования" ещё вот тут: https://www.facebook.com/Nashev.ru/posts/10212049102261765 -- и тут явно форма победила содержание: на картинке критикуется образование, а в обсуждении почему-то всплывают ЕГЭ и вступительные экзамены, как будто на картинке речь идёт о них!
[ << Previous 20 ]
Лабораторный журнал   About LiveJournal.com