Анатолий Левенчук – Методология 2025 (страница 18)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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