Методология 2025. Анатолий Левенчук

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

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

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

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

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

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

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

      Пример

60

https://habr.com/ru/articles/505928/