Но уже сейчас для практических целей записи алгоритмов для методов можно использовать идеи, например, функционального программирования, ибо метод и функция по факту синонимы, и эта парадигма программирования хорошо приспособлена для записи таких программ с «ленивыми вычислениями» (то есть никакие методы не используются, пока для них не появится подходящих условий их задействования). В жизни это будет «планирование на лету» (скажем, описание лечения пациента, которого привезли в больницу. В каждом кабинете ему могут выполнить какую-то процедуру – сделать укол, взять анализ, провести физиотерапию, провести хирургическую операцию, покормить, но последовательность этих процедур заранее неизвестна – дело не только в том, что первичный диагноз будет уточняться, но и состояние больного будет меняться, часто непредсказуемо. Поэтому никакого up front алгоритма нельзя составить, всё будет планироваться «на лету», «гибко», «в рабочем порядке»).
Но можно применять и идеи автоматного программирования70 (задействование «автомата» как машины состояний), использовав понимание, что предмет метода проводится через какие-то состояния в графе его состояний. Основная мысль тут: при любой попытке поднять формальность описания способа работы вы упрётесь в хорошее понимание программирования, хорошее понимание алгоритмики в плане парадигм программирования (выражение алгоритмов) и определение сложности «созидательных программ» (обобщение компьютерных программ на программы для создателей), чтобы оценить потребные ресурсы и оценить время выполнения работ по методу.
Кроме алгоритмики для методологических рассуждений нужно привлекать и много других методов мышления, расположенных ниже по интеллект-стеку. Например, рациональность как способ выбора из множества вариантов методов. Об этом в нашем курсе будет позже, когда мы будем обсуждать стратегирование.
А пока подчеркнём, что при попытках записи каких-то методов надо бы обращать внимание на алгоритмику и её опыт.
Автор этих строк в качестве первого рабочего задания после университета (1980 год) получил задание создать язык для описания строительства здания – и не знал, что он попал в отдел, который как раз занимается проблемами AI на базе класса систем, известных как «фреймовые»71 (кодирование методов в структурах данных для «стереотипных ситуаций»). Постановка проблемы была примерно такой: «давай опишем алгоритм строительства дома на каком-то языке. Но мы знаем продолжительность каждой операции и требуемые ресурсы – для этого у нас есть СНиПы, строительные нормы и правила. Затем мы просто посчитаем длительность стройки в компьютере. Так что дай нам соответствующий язык описания». Конечно, в головах у всех в 1980 году был именно императивный подход к таким описаниям – который доблестно провалился, поэтому и обратились к фреймовому подходу в AI. Но как описывать эти «фреймы» и как находить их в жизни? Попытки сначала сделать язык для чего-то маленького (конечно, автор через пару недель попытки описания стройки понял, что проблема пока никому не по зубам, хотя за неё брались многие – но был молод и не отчаивался, поэтому просто решил пойти через решение более простых проблем), например, сделать язык формального описания для книг кулинарных рецептов, тоже ни к чему не привели. И только после многих лет автору стало понятным, почему всё было так плохо и почему идеи методологии трудно показать в их формализме на уровне, достаточном для автоматической/машинной реализации метода (а ведь вся цифровая трансформация – она про это!):