Милонги (вечеринки танго) в семестре “Системного мышления и методологии”
Первая открытая группа “Системного мышления и методологии” без моего участия (группу ведёт Юлия Чайковская) только что прошла экватор курса, так что можно уже обсуждать серьёзные проблемы. Ну, я тоже принимаю участие в обсуждении – как и обещал, я вполне участвую в работе группы. Сегодня состоялось интересное обсуждение по поводу целевых систем, но как всегда – проблемы в типах, а не в собственно системном мышлении.
Обсуждалась вечеринка танго – ровно многоуровневый пример из учебника (но один из участников группы препод танго, диджей танго, орг вечеринок, так что обсуждение было более чем конкретным). Но обсуждение пошло не по линии танцоров, а по линии диджея. И там всплыла та же ошибка с типами (целевая система диджея – это плейлист), что и приведённый в учебнике пример с ошибкой – “целевая система хореографа – листок с описанием фигур танца”. Но ошибка не приходит одна: дальше сразу будет путаница во временах – какое время для диджея dev time, а какое ops time? Но самое главное – быстро как с примером танца тут разобраться не получится, потому как основной режим работы диджея – это принимать решения по поводу плейлиста “в реальном времени”, отслеживая состояние танцпола и ставя треки “по настроению”.
Дело преподов (всё больше и больше в этом убеждаюсь) на курсе – это не просто давать быструю обратную связь по ошибкам. Действительно, однокурсники чаще всего не успевают разобраться – и ошибка в рассуждениях проходит незамеченной. Дело преподов – давать пояснения по ошибкам, связанным с будущим материалом курса, возможно, даже будущим материалом следующего курса или даже следующего семестра. Так и тут: давайте поглядим на онтику того, что делает диджей. “Делает диджей” – это сразу отсылка к материалу курса “Методология”, ибо “делает” – это про метод.
Разложение метода работы диджея
В разложении метода работы диджея есть три основных метода:
— диггерство: “нюхает” публику и подбирает музыку под настроение зала, у него там “подстройка — ведение” (подроль диггера — диггеры нарывают какой-то трек, его подают вовремя по ходу вечеринки как “бриллиантовый хит”, все в восторге. У диггера особое музыкальное чутьё и особое чутьё настроения зала).
— игра: бесшовное в плане ритмики, громкости, тональности, темпа и прочих параметров музыкальности сведение треков, мастерское владение инструментом – диджейским пультом, это и есть “игра диджея”, конкурсы диджеев и школы диджеев обычно про это (подроль музыканта)
— выставлять нормальный звук в зале (звукооператор, уметь работать с аппаратурой и акустикой — и там многое зависит даже от наполнения зала, подроль “продюсер”)
Танго-диджеи обычно только про первое, поэтому им и учиться обычно не надо, просто играют “по наитию”. А в кизомбе, например, принято сводить/играть — и даже при передаче ведения от одного диджея другому. И диджеев тоже трое-четверо на вечеринку, с расписанием кто-когда. Но разговор о танго, поэтому там “диджейство” условное. Разбираем только подроль диггера: умение пойти в магазин винила, “нарыть” там трек (dig – “выкопать” из завалов винила) и выдать его вовремя на танцпол. “Вовремя” – это в подходящий по настроению момент. Это означает, что плейлиста нет. Но какой тип у объекта “плейлист”, “список треков, которые звучат на вечеринке”?
Плейлист — это проект/design::описание того, что играет? Или то, что появляется потом (после игры) как описание сыгранного? Или играемое – это работы “проигрывания трека” и плейлист::проект/project::описание? Up-front планирование, чёткое предсказание настроения? Понятно, что такое не выживет, “водопадное планирование” не работает даже на вечеринках. Ну, и где тот плейлист, когда я прямо сейчас как диджей определяю, что будет играть — планирую “на лету”, никаких списков в природе нет? Что это за объект такой, какова его “вещность”, как называется то, что звучит? Тут, похоже, тоже одним словом “плейлист” много чего называют.
Похоже, что плейлист – это какая-то программа, заставляющая диджейскую аппаратуру играть правильный набор треков в правильное время. Ну вот похоже, что “плейлист” это программа, равно как и мастерство диджея программа. Скажем, диджей создаёт плейлист, посылает его по почте оргам, а орги ставят этот плейлист (говорят при этом, что играет “диджей флешка”, а диггер постарался, создал микс и сыграл его на своей аппаратуре – дальше справляется флешка с готовой записью музыки, вставленная в диджейский пульт).
Как рассуждать о коде программы, если код составляется на лету по мере его интерпретации?
Но давайте примем, что плейлист – это программный код для плеера, плейлист в плеере становится софтом, который управляет инструментами плеера как создателя. Помним, что создатель необязательно полноценный агент. У Дойча создатели – молекула катализатора, станок с программным управлением, робот с зачатками автономной работы и даже саморепликации, живое существо – тот же человек. Плеер тут вполне сойдёт как “станок с програмным управлением”, который под управлением программы (плейлист становится программой в плеере, куда мы добавим и актуаторы-колонки) управляет колебаниями воздуха.
Как же рассуждать о программах, которые составляются “на лету”?
Один из возможных ходов тут – обозвать “плейлистом” не то, что должно прозвучать, а то, что уже прозвучало в ходе диджейской игры, “историю”.
Вопрос, кстати, для софта о том, как работать с кодом программы, который составляется “на лету”, очень хитрый (даже пытались термин для этого сделать – Exploratory programming - Wikipedia, и там сразу идём в “интерпретируемые языки”, а ещё в современном программировании это развивается в виде Notebook interface - Wikipedia с отсылками к Literate programming - Wikipedia).
Для кода программы (код программы – описание алгоритма, программа – это алгоритм в памяти вычислителя, и на этот алгоритм передано управление, пошёл физический процесс, меняются вольт-амперные характеристики деталей вычислителя, вычисляются конкретные значения переменных как структур памяти в вычислителе, вычислитель в ходе физического процесса меняет состояния) есть три режима исполнения физическим вычислителем (компьютером):
– Интерпретация (берём команду, исполняем её, берём следующую команду),
– компиляция (берём текст, преобразуем в команды — идём в интерпретацию) и
– “непосредственное исполнение” (режим, часто вообще упускаемый), это когда вы работаете “с пульта”, например, двигаете курсор по странице Ворда. Понятно, что там вроде как отрабатывает дальше какой-то софт, но нажатие клавиши в физическом мире при этом как-то преобразуется в команду, то есть событие физического мира становится событием исполняемой программы. Это как раз то место, где все эти функциональные монады ломаются (ввод-вывод и всякие прочие неудобства, из-за которых страдает теоретическая стройность функционального программирования).
Это довольно легко обобщается с “вычислителя” (работа с информацией) на constructor для любых преобразований. Поэтому дальше мы будем “код программы” (информация) и “программу” (физический объект в компьютере, производящий вычисления) понимать обобщённо – как код не просто преобразований информации (вычисления), но преобразований физического мира создателем, а программу – ту часть создателя, которая управляет его работой по преобразованиям физического мира (и даже ещё меньше – часть контроллера/вычислителя создателя).
Интересно, что код программы можно получить, даже если речь идёт о режиме непосредственного исполнения (например, идёт какая-то “импровизация”, я нажимаю на кнопки с пульта, ориентируясь на изменения ситуации между нажатиями кнопок). Если вы в Ворде будете что-то делать, включив режим записи макро, то на выходе получите код программы на визуальном бейсике, которая может повторить ваши действия. Дальше вы можете эту программу откомпилировать и отинтерпретировать. Тем самым вы сможете повторить вычисление.
Итак, если плейлист — это код программы для плеера, то его можно:
– интерпретировать (и программа плеера будет играть на предназначенном для него “вычислителе”, аппаратном диджейском плеере или компьютере со звуковым чипом. Плейлист, который по факту проигрывается как программа вашим музыкальным станком с “числовым программным управлением”, ЧПУ. Этот плейлист ведь ровно как “код программы для станка с ЧПУ”, плеер с аудиочипом и колонками ровно как этот станок с ЧПУ: станок переводит изменения физического состояния программы в изменения физического состояния (положения, скорости вращения) обрабатывающих головок станка с ЧПУ, а плеер с аудиочипом и колонками переводит программу в изменения состояния воздуха (колебания, звуковые волны), воспринимаемые нами как “звучащая музыка”).
– компилировать (написать, отослать по почте, переделать в формат какого-то плеера, он будет играть его в его “машинном языке плеера”),
– но можно представить и режим непосредственного исполнения “с пульта”, когда вычислитель-плеер есть, а программы-плейлиста нет, вместо неё есть воздействия диджея. Но если в плеере записывать “историю” (log, журнал), то плейлист появится.
Примеры режима “непосредственного исполнения” (“с пульта”)
То же самое можно говорить про многие другие ситуации, когда кода программы вроде нет, но “задним числом” его можно получить как “макро ворда” или “историю плеера”, если записать “непосредственное исполнение”. Вот списочек “кодов программ”, как они бы назывались по типу, если их записать и перевести в знаки:
– логи/журналы (лабораторные, бортовые, ремонтов, бухгалтерские, работы софта и т.д.): ещё можно собирать состояния программы в ходе непосредственного её исполнения в логи (log – “бортовой журнал”, блог – blog от weB-LOG, “журнал от повсеместно протянутой паутины, WWW”). Потом, используя логи, можно пробовать что-нибудь понять про ситуацию, а потом пытаться её воспроизвести (тем точнее, чем подробней будут логи). Скажем, вы ведёте лабораторный журнал (у меня блог не случайно так называется!). Потом можно пытаться по записям в лабораторном журнале воспроизвести эксперименты этой лаборатории, поддержать “воспроизводимость экспериментов” в науке. Общее название “записанного по итогам operations управляющего кода” было бы тут, конечно, не только “лог/журнал”, но и не менее общее “история”, в плеере плейлист отыгранного можно найти именно под таким именем. В программах asset management журналы так и называются “исторические данные”, но нам нужны не безличные “работы из истории”, а содержательные методологические имена
– партитура: если запишете, что там играли джазовые музыканты в ходе импровизации на своих инструментах, получите партитуру. Потом можно изучать, смотреть принципы и делать всё то, что делается с обычной музыкой – в существенной мере снимается противоречие классической (нотной) музыки и импровизационной, см. Владимир Мартынов, “Музыка и письмо”, Музыка и письмо. Скажем, вы импровизируете на рояле, записываете видео – одна форма представления истории, но в ней нет знакового представления! Так что это ещё не код программы, хотя тут и нюансы – колонки ведь потом всё одно отыграют продемонстрированный паттерн, но не паттерн работы управления роялем, а итоговый паттерн звучания рояля, так что видеозапись – это тоже алгоритм смены состояний пикселей на экране и положения катушек на колонках, тоже “плейлист”. Но мы можем использовать сервис получения партитуры из этой “видео и звуковой истории”, Piano2Notes - Turn Piano Music into Notes | Klangio (варианты для разных других инструментов кроме рояля: https://melodyscanner.com/). Вообще, можно много обсуждать то, как устроена импровизация в головах музыкантов, какие у них паттерны – просто это не по линии семантики с семиотикой, а по линии семантики с распределёнными представлениями (смотри конец 12 раздела курса “Системного мышления”, картинку сдвоенного треугольника Фреге – с локальными символьными представлениями и распределёнными представлениями).
– папка “дело”: в смысле case file, классика кейс-менеджмента. Кейс – это судебное дело, а case file – папка “судебное дело” (впрочем, история болезни – то же самое, кейс-менеджмент). Дело ведётся вновь открываемыми обстоятельствами, что делать дальше, придумывается на ходу. Но зато всё, что делается и что при этом найдено – записывается. По идее, можно воспроизводить потом какие-то фрагменты из кейс-файла как удачно найденные шаблоны (community template в адаптивном кейс-менеджменте). Управление кейсами/case management как раз на этом построено, в “Методологии” много об этом говорится. Есть тут и тесная связь с одним из вариантов прикладной методологии собственно методологии – ситуационной инженерии методов. В ситуационной инженерии методов вы пытаетесь сделать разложение метода в одной ситуации на chunks, fragments, slices, а затем пересобрать из этого разложения метод “по ситуации”. А откуда берём разложение метода? Тут хитро: берём какое-то исполнение метода и переводим исполнение каких-то паттернов в символьное представление (моделируем) в заранее предписанных типах (этих самых chunks, fragments, slices). Стандарт OMG Essence – это как раз последний в линейке стандартов ситуационной инженерии методов (situational method engineering), который отличается тем, что предполагает не лёгкость моделирования, а лёгкость выполнения метода по предъявленному шаблону.
– кулинарный рецепт: очень многие хозяйки готовят еду не по рецептам, а “из головы” (метафора у них при этом – “рисую кулинарную картину”, чтобы уж точно исключить какие-то “рецепты”). Чистое творчество, “готовлю из того, что нашлось, даже не знаю, что получится”, при этом мыслей о готовке в терминах “рецепта” нет. Как в случае музыки (и плейлиста, и партитуры) можно пробовать записать видео, а затем считать и само это видео “историей”, и дальше пробовать восстановить рецепт в знаковых локальных представлениях (как рецепты в кулинарной книге), если распознаватель паттернов (какая-нибудь продвинутая нейросетка следующего поколения, возможно даже человек-кулинар) владеет языком изложения этих самых рецептов (“варить до готовности”, “пассеровать”).
– хореография: вообще-то это запись танцевальных движений, но в импровизационных танцах хореография не составляется, танцевание идёт “непрерывно открывающимися обстоятельствами музыки, текущей инерции и состояния равновесия, окружения в виде зрителей и партнёров по танцу, шероховатости пола”, хотя иногда вставляется “community template” из заученной из культуры или заранее придуманной перед импровизацией последовательности движений. Так что хореографии как записи у импровизационного танца нет, но всё-таки ход тут тот же: запись на видео, потом воспроизведение “по видео”, но можно потом записать танец в какой-то нотации (вот тут небольшая библиотечка на эту тему: dance notations — Яндекс Диск).
– … список можно продолжать и продолжать. Придумайте ещё три-четыре варианта “импровизационного исполнения программы с пульта”, а потом превращения её “задним числом” в какой-то код для аппаратуры-создателя.
Методология – это алгоритмика-на-стероидах
Чтобы формализовать импровизацию как синтез метода “по ходу дела”, “динамическое стратегирование”, требуется тем самым хорошо знать азы информатики, как минимум:
– информатика как работа агентов и людей с текстами и кодами (Информатика: ailev — LiveJournal), все оттуда перетекстовки/парафразинг (из текста в текст), кодирования (из текста в код), отекстовки (из кода в текст), перекодированияирования (из кода в код) и нюансы “всё есть текст”, связанные с локальными и распределёнными представлениями (до сих пор обсуждение шло с классической семиотикой, но есть же и обучение представлениям).
– отличия кодов (абстрактные объекты) и программ (физические объекты), размытая граница между “софтом” и “аппаратурой”. Грубо говоря, “если моя мысль нематериальна, то что тогда поднимает мою руку”. Все эти “стеки виртуальных машин”, часть из которых реализована аппаратно, а часть – программно (включая микропрограммы в аппаратуре). Добавьте квантовый и оптический компьютинг. Добавьте распределённые представления (скажем, спайковые нейросети) и ходы на универсальные алгоритмы (AI) и no free lunch theorem.
– обобщение вычислителей до создателей (обсуждается, например, в https://www.youtube.com/watch?v=40CB12cj_aM – “Paradigm Shift, Ghost Particles, Constructor Theory”, Chiara Marletto, 2024).
– разбирательство с формализом вычислений, например, теория категорий – и почему все эти “монады” взрываются простыми операциями ввода-вывода (несуществование “сферических программ в вакууме”, физичность вычислений таки рулит).
Дальше можно развлекаться с тем, какие там роли у диджея: диджей, музыкант, хореограф, кулинар, исполнитель кейса, создающие “на лету” (выполняя действия с инструментами “с пульта”) то, что “задним числом” будет в “истории” плейлистом, партитурой, хореографией, рецептом, кейс файлом – это всё в обобщении “программисты-импровизаторы”. Создатели, работающие в режиме “записи макро”, использующие при этом какие-то уже имеющиеся шаблоны действий как команды виртуальной машины, запускаемые “с пульта” (тут помним про курс алгоритмики мехмата МГУ, различающий выполнителя программы и исполнителя как выполняющего предзаданные функции в выполняемой выполнителем программе, минимум два уровня программирования. Это типичное “диджейство” – игра музыки на основе существующей музыки, “двухуровневая игра”, отражение в техноэволюции “закона возрастания сложности” из работ группы Ванчурина, https://www.pnas.org/doi/10.1073/pnas.1807890115).
Увы, хорошо информатике нигде не учат. Кодировать на языке программирования — учат. А вот computer science — не учат, это беда (обсуждали с физтехами, которые читали “Интеллект-стек” – да, самым азам не учат, учат “разделам физики и математики, разделам информатики”). У меня на эту тему есть:
– раздел алгоритмики в “Интеллект-стеке”, Aisystant
– докрутки 2024 года, Алгоритмика-2024: ailev — LiveJournal
– курс “Методология” в текущей версии (там про это весь первый раздел), Aisystant
– вот этот пост, написанный по мотивам дискуссий в текущей учебной группе.
Методология – это как раз и есть “алгоритмика-на-стероидах”, ибо прихватываем преобразования физического мира создателями под управлением каких-то программ.
Примеры моего диджейства (включая перенос навыка в компьютер, “цифровая трансформация диджеинга”)
Я занялся диджеингом в марте 1977 года, это была первая дискотека в Ростове-на-Дону. Дальше я создал университетскую школу диджеев, и даже выписал себе (поскольку сам и преподавал) в 1980 году диплом факультета общественных профессий РГУ по специальности “руководитель дискотеки” (про системные уровни тогда ничего не знал, но уже понимал, что рулить пультом диджея и рулить дискотекой – это разное, и лучше бы рулить дискотекой, а рулёжка пультом диджея там где-то внутри).
Один из последних моих диджейских экспериментов – это научить моему музыкальному вкусу нейродиджея Яндекс.музыки (то самое “обучение представлениям”, representations learning для распределённых представлений, distributed representations), а затем поручение создать плейлист “на лету” в ходе танцевальной вечеринке на набережной в парке Горького. После чего берём и документируем результат – получаем плейлист той вечеринки, это я делал ещё в 2022 году: Вчера после полуночи на набережной в ПГ я оказался.. | Anatoli Leventsjoek | VK. Послушайте, получите удовольствие. Это как раз демонстрация ходов на автоматизацию, которые можно обсуждать в предложенном в “Методологии” и текущем посте наборе понятий:
– имеем “исполнение с пульта”, но записываем (доступна “история”, case file). Тут было немного хитро: генератор случайных чисел играл треки, надо было лайкать. Вот “лайкнутое” – это и была “игра того, что нравится”. Всё, конечно, немного сложнее, но суть в накоплении “плейлиста истории лайков”.
– универсальный/обучаемый алгоритм (нейродиджей Яндекса) смотрит запись “ручного исполнения, то есть историю лайков”, восстанавливает из неё алгоритм “лайкания” (то есть алгоритм моего мастерства диджея – мастерства отбора треков, хотя и без части “нюхать обстановку в зале и ставить уместный”, то есть это только часть мастерства)
– во время вечеринки из всей фонотеки выбираются только те треки, который прошли “фильтр отмоделированного мастерства отбора треков”. Результат записывается в ту же “историю плеера”.
Вот абзац выше – это ведь тоже описание метода (хи-хи, “метод цифровой трансформации диджеинга”).
Собственно, весь пост про то, что для подробного обсуждения подобных ситуаций хорошо бы иметь развитый предметно-ориентированный язык, а не сочинять этот язык каждый раз, обращая внимание не на важное, а на что пришло в голову первым. Этот язык обсуждения важного в любом деле оказывается языком методологии. Он позволяет видеть общее в самых разных ситуациях, которые встречаются тебе впервые. Например, видеть общее в кейс-менеджменте, диджейской, джазовой, кулинарной, танцевальной импровизации.
И даже “автоматизация импровизации”, если поглядеть на неё уровнем выше, оказывается в удобной постановке: это же рекомендательные системы! Тот самый “нейродиджей” – это же рекомендательная система! Примерно то же самое можно сделать и для всех остальных “импровизаций”: предложение очередного шага в “программу на лету”, определяемое порождающей моделью, учитывающей предыдущие сделанные шаги, привходящие внешние обстоятельства и имеющей выученную модель предпочитаемых действий в какой-то предметной области.
На фото: я веду дискотеку 70х (это примерно 1979 год), гостевой визит дискотеки РГУ в ростовский мединститут. За магнитофоном наш звукооператор Шурик Шиф (разделение труда диджея было уже тогда!), хотя у нас и винил был – но диджейских пультов не было, поэтому ничего не сводили “классически”, а неизбежные при этом паузы между треками диджей заполнял своей ритмичной речью. Но даже тогда играл не “диджей флешка” (о флешках тогда, кстати, и мечтать нельзя было, правильней было бы сказать “диджей катушка магнитной ленты с предзаписью”), а было живое ведение: плейлист составлялся всегда “на лету”, под настроение зала. Впрочем, примерно так же играют сейчас и на танго, и на хастле, и в модерн свинге: там тоже нет сведения, звукооператор частенько – отдельный человек, а диджей “нюхает настроение” и выбирает следующий трек, руководствуюясь “вновь открываемыми обстоятельствами вечеринки”.
UPDATE: Обсуждение с Telegram: Contact @comp_thinking