Давным-давно, начиная лекцию об алгоритмах, в те времена, когда о них говорили как об отдельной сущности, рисовали в виде блок-схем перед тем, как писать код программы для их реализации, я задавал студентам вопрос: "Куда девается дырка от бублика?" И тут же отвечал на этот дзен-вопрос: "Никуда, потому что в мире Идей ничего не умирает. Дырка от бублика — самый яркий тому пример. Если мы представим, что тело бублика — это код программы, а дырка — это тот невидимый и подразумеваемый Алгоритм, который этот код реализует."
Один студент даже предположил в ходе обсуждения, что дырка должна существовать до появления бублика. Дырка первична. Дырка, или пустота внутри бублика — это Алгоритм в голове программиста, который он должен записать в виде инструкций для Исполнителя-Компьютера. Так и получается код программы или тело бублика.
Я начинал свои занятия про алгоритмы со студентами с вопроса "Куда девается дырка от бублика?" только с одной единственной целью — показать им, что код программы — это не алгоритм, а инструкция для Исполнителя-Компьютера, написанная на языке программирования.
Очень много проблем с поддержанием и внесением изменений в программы происходит как раз от того, что они — программы-бублики, и мы не знаем, какой Алгоритм они реализуют. Описание Алгоритма находится где-то в голове программиста или в отдельных документах. А если сменится программист или изменения в коде не найдут своего одновременного отражения в описании Алгоритма, то очень сложно разобраться, куда катится бублик.
Не могу сказать, что человечество не пыталось решить эту проблему, но оно почему-то увлеклось созданием тысяч языков программирования в попытке облегчения написания и понимания кода, тогда как бублик оставался бубликом с дыркой внутри. Уточню, что я имею в виду. Какой бы совершенной ни был язык программирования, он предназначен для создания тела бублика. Алгоритм и код программы продолжают жить самостоятельной жизнью во всех программах-бубликах.
К сожалению, мало что изменилось с появлением ИИ и созданием различных копайлоторов на его основе, таких как GitHub Copilot, потому что все они помогали программистам писать и модернизировать тело бублика, но не решали проблему существования алгоритма отдельно от кода. Это происходило еще и потому, что они были обучены и натренированы на программах-бубликах, созданных по методологиям, предполагающим существование кода отдельно от алгоритма.
Три года назад я сформулировал понятийный аппарат и идеологию новой методологии программирования.
С моей методологией VAOP (V-Agent Oriented Programming) алгоритм не существует отдельно от кода. Вместо того, чтобы сначала рисовать блок-схемы, а потом писать код, мы сразу пишем код, который инкапсулирует алгоритм. Это превращает наши программы из бубликов в коржики, где нет пустоты — весь код имеет смысл и цель, оставаясь компактным и устойчивым.
Вот чему надо учить ИИ, чтобы он мог сразу взаимодействовать с заказчиком и программистом. Для этого надо создать VAOP-copilot, который может работать помощником как программиста, так и заказчика, потому что в том «алго‑коде», в коржике, который он помогает писать по методологии VAOP, есть и бизнес‑логика, и инструкция для Исполнителя‑Компьютера. В идеале заказчику не нужен будет программист. Достаточно обсудить с VAOP‑copilot алгоритм или бизнес‑логику, и коржик готов. Продолжая делать программы‑бублики, вы никогда не добьетесь такого результата, и никакие копайлоторы без VAOP методологии вам не помогут сделать из бублика коржик.
Я хочу закончить эту статью тем, чтобы сказать, зачем я ее написал. Написал я ее с единственной целью — ввести эти два новых понятия в мир программирования:
программы-бублики ["Bagel programs" (programs with a hole or without Algorithm)] и
программы-коржики ["Maffin programs" (programs without a hole or with Algorithm)].
Я считаю это действительно важным для дальнейшего развития и создания методологий и методов программирования.
