Представление метода работы как алгоритма: методология как алгоритмика-на-стероидах

Материал этого раздела весьма сложен, может оказаться, что вам нужно освежить азы алгоритмики. Как минимум, вы проходили алгоритмику в школе, возможно, сдавали по ней ЕГЭ, но методология требует, конечно, не школьного понимания алгоритмики. Увы, даже азам алгоритмики мало где учат. Мы можем указать на курс «Интеллект-стек» и дополнительные материалы к этому курсу⁵⁸, посмотрите там, чем же занимается алгоритмика. Конечно, программистам материал этого раздела будет понимать легче, но наш опыт показывает, что и это не всегда так: материал отсылает не к «программистскому опыту», а к теоретическому знанию – объяснениям азов алгоритмики в её связи с математикой и физикой. Увы, этому даже в вузах учат отнюдь не всех «программистов с высшим образованием».

Мастерство выполнения метода – программа, которая описана алгоритмом. Мы пока опустим тот нюанс, что алгоритма совершенно недостаточно для описания программы, ибо программа – это алгоритм плюс структуры данных⁵⁹, да ещё и реализованные каким-то вычислителем (подробней это обсуждалось в курсе «Системное мышление»). В случае методов мы говорим, что создатели – это обобщение «вычислителя» до «создателя» (то есть не только работаем с данными на входе и получаем данные на выходе, но берём какие-то предметы метода на входе и получаем предметы метода на выходе – делаем физические преобразования). Так что «программа метода» понимается не просто как «вычислительная программа», а как «преобразовывающая мир», «программа для станка с ЧПУ» в простейшем случае. А если создатель умный и эта программа – алгоритм в мокрой нейросети, или даже гибридной нейросети предприятия (из мокрых нейросетей множества людей и компьютерных сухих нейросетей плюс много компьютерной памяти и ещё станки в поддержку вычислений и преобразований), то мы назовём её «мастерство».

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

С подробным описанием метода плохо справится даже граф (визуально это будет «диаграмма», «принципиальная схема» и небольшое количество типов узлов графа и типов рёбер графа), но хорошо справится алгоритмическое представление в виде:

• алгоритма и предметов метода на естественном языке, это самая маленькая формальность представления метода на шкале формальности

• алгоритма и предметов метода на псевдокоде (похоже на какой-то формальный язык – но на самом деле формализация недостаточна для полностью машинного выполнения на классическом компьютере с языком программирования)

• алгоритма и предметов метода в виде кода на каком-то языке программирования, полностью формальное (подразумевающее «машинное» однозначное) выполнение.

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

Пример замечателен тем, что описание разложения методов как алгоритма даётся сразу для создателя, то есть описываются действия в реальном физическом мире, а не с данными программы. Но весть текст статьи – про программирование и потоки данных в функциональном подходе к описанию алгоритмов, а не потоки управления в императивном подходе. А в примере – потоки предметов метода, а не потоки данных, то есть изменение состояния объектов в реальном мире.

В самом тексте делается попытка объяснить программистам, что же такое функциональное программирование, и зачем оно нужно (таких текстов тысячи!), и зачем там вообще нужна математика, включая не самый её простой раздел – теория категорий⁶¹. Автор курса многократно сталкивался с тем, что профессиональные программисты буквально сражаются за то, чтобы разобраться с функциональным программированием, оно очень нелегко даётся. Но те, у кого произошла метанойя (термин объяснялся в «Системном мышлении») уже не помнят, что там у них было сложного – поэтому комментарии к этим всем статьям разнятся от «всё равно сложно, ничего не понял» от новичков до «зачем это разжёвывать, ничего сложного» от давно прошедших метанойю.

Тут можно напомнить, что когда-то школьное программирование вводилось в школах СССР в 1985 году ровно как попытка научить школьников планировать какие-то последовательности действий с условиями, описывать какое-то поведение. Под планированием имелось в виду не ресурсное планирование, то есть составление плана-графика (кто когда что с чем делает), но как раз методологическая работа – описание того, что вообще надо делать. В обосновании звучало, что выражению алгоритма как описанию каких-то действий (слово «метод работы» тогда не звучало, в лучшем случае звучало «описание работы», а не «описание методов работы») не учат ни в одном предмете, изучаемом в школе – физика, математика, география и любой другой предмет мог сам рассказывать о каких-то методах работы, но вот записать какой-то метод работы хоть в каком-то формальном виде ни один предмет не учил. Как и во всём мире для обучения школьников, для выражения алгоритма был выбран императивный язык.

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

Так что для возвращения тематики «обучения составлению алгоритмов выполнения работ» в обучение программированию нужно сделать довольно много:

• Сразу вводить понятие метода как работ не только с описаниями (абстрактными объектами, информацией, работы с данными – «компьютерное программирование»), но и с предметами метода. Алгоритмика не компьютерная, а созидательная (программирование создателей/constructors из теории создателей).

• Добавить обсуждение работы с типами предметов метода (а не только типами данных и структурами данных), ибо программа = алгоритм плюс данные.

• Алгоритмы надо будет выражать на декларативном (скорее всего, функциональном) языке. Хотя, по большому счёту, нужно владеть мультипарадигмальным программированием – ибо для разных вариантов алгоритмов удобней разные варианты парадигм программирования⁶², отражённые в разных языках программирования, всё большее число современных языков программирования сегодня – мультипарадигмальные языки, поддерживают и процедурную, и функциональную парадигмы.

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

Алгоритмика сама по себе связана как с выражением способа вычислений на языке какой-то парадигмы (выражение способа – это методология), так и скоростью вычисления (это операционный менеджмент, исследование операций), что зависит от физики компьютера. Так что алгоритмика – экспериментальная наука, физика компьютера вносит реализм, а формальность вычисления – математику. Поскольку каждая программа – это доказательство (соответствие Curry-Howard⁶³), то соответствие физического процесса в компьютере (классическом, квантовом, оптическом и т.д.) и абстрактного процесса вычислений «в математике» может быть проверено только экспериментально, через экспериментальную науку. Deutsch прямо называет алгоритмику «наукой о доказательствах», ведь программы – это доказательства, конструктивная математика – это программирование, и дальше через алгоритмику можно делать ходы на выполнение доказательств (алгоритмов) на компьютерах, проекты унивалентных оснований математики и языков Agda и Coq как раз нацелены на помощь математикам со стороны компьютерной техники (подробней об этом – в курсе «Интеллект-стек», и там много ссылок на литературу).

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

Алгоритмика должна экспериментально подтверждать, что алгоритм эффективно выполним на каком-то железе. В силу no free lunch theorem нет универсально быстрого алгоритма для всех задач, для разных ситуаций будут эффективны разные алгоритмы, а разница в эффективности алгоритмов на разном «железе» с разной физикой может быть драматической, в пересчёте на методы – это как копать котлован лопатой по сравнению с экскаватором, по сравнению с гидромеханическим размытием, по сравнению со взрывным способом. Методология с задействованием исследования операций в паре с операционным менеджментом должна экспериментально подтверждать, что создатель с его мастерством (реализованным тоже аппаратно!) и инструментарием (tooling), реализуя метод, будут получать результаты заданного качества/точности (предметы метода в заданном состоянии) в приемлемое время и при приемлемом расходе ресурсов. В алгоритмике говорят, что синтез алгоритмов должен быть hardware aware для того, чтобы алгоритм был эффективен. Вот и метод должен быть оптимизированным по инструментам (hardware aware), то есть учитывать наличные особенности инструментария, включая аппаратуру для мастерства как «управляющей программы».

Алгоритм – это вроде как последовательность вычислений, а тут – последовательность каких-то трансформаций для создателя, обобщение алгоритма для вычислителя (машины Тьюринга) на материальный/физический мир. И тут надо разбираться с теоретическими обобщениями, например, constructor theory⁶⁴ как обобщения машины Тьюринга как универсального вычислителя в сторону универсального преобразователя. С помощью подобной теории мы можем пробовать выдать какие-то достижения современной алгоритмики за начальные идеи в методологии, мы вполне можем понимать алгоритмы как «алгоритмы в том числе для станка с ЧПУ» и теории не математические, а вполне себе теории про реальный мир.

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

В существенной мере алгоритмы методов работы зависят от представления/representation знаний о предметной области: алгоритм сложения чисел с мастерством, реализующимся мокрой нейронной сеткой в человеческой голове, даже при условии её усиления ручкой-бумажкой для безошибочно работающей памяти и облегчения удержания внимания существенно зависит от нотации. В римской нотации всё плохо, а в арабской⁶⁵ нотации (позиционная запись и явно представленный ноль) – даже дети справляются не только с умножением десятизначных чисел, но и с делением, что казалось бы чудом ещё тысячу лет назад. Есть разница с нотациями, которые пригодны для непосредственно мышления об объектах (операции со знаками соответствуют операциям в реальном мире – вот как с арабскими цифрами, «рассуждение легко алгоритмизируется»), и «описаниями» каких-то операций в естественном языке или даже псевдокоде, которые не так-то легко алгоритмизируются⁶⁶