Давным-давно, начиная лекцию об алгоритмах, в те времена, когда о них говорили как об отдельной сущности, рисовали в виде блок-схем перед тем, как писать код программы для их реализации, я задавал студентам вопрос: "Куда девается дырка от бублика?" И тут же отвечал на этот дзен-вопрос: "Никуда, потому что в мире Идей ничего не умирает. Дырка от бублика — самый яркий тому пример. Если мы представим, что тело бублика — это код программы, а дырка — это тот невидимый и подразумеваемый Алгоритм, который этот код реализует."
Один студент даже предположил в ходе обсуждения, что дырка должна существовать до появления бублика. Дырка первична. Дырка, или пустота внутри бублика — это Алгоритм в голове программиста, который он должен записать в виде инструкций для Исполнителя-Компьютера. Так и получается код программы или тело бублика.
Я начинал свои занятия про алгоритмы со студентами с вопроса "Куда девается дырка от бублика?" только с одной единственной целью — показать им, что код программы — это не алгоритм, а инструкция для Исполнителя-Компьютера, написанная на языке программирования.
Очень много проблем с поддержанием и внесением изменений в программы происходит как раз от того, что они — программы-бублики, и мы не знаем, какой Алгоритм они реализуют. Описание Алгоритма находится где-то в голове программиста или в отдельных документах. А если сменится программист или изменения в коде не найдут своего одновременного отражения в описании Алгоритма, то очень сложно разобраться, куда катится бублик.
Не могу сказать, что человечество не пыталось решить эту проблему, но оно почему-то увлеклось созданием тысяч языков программирования в попытке облегчения написания и понимания кода, тогда как бублик оставался бубликом с дыркой внутри. Уточню, что я имею в виду. Какой бы совершенной ни был язык программирования, он предназначен для создания тела бублика. Алгоритм и код программы продолжают жить самостоятельной жизнью во всех программах-бубликах.
К сожалению, мало что изменилось с появлением ИИ и созданием различных копайлоторов на его основе, таких как 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)].
Я считаю это действительно важным для дальнейшего развития и создания методологий и методов программирования.
Комментарии (19)
dezahrise
19.05.2024 00:03+5А-ля подобных кодогенераторов и сейчас много. Где лоу код инструкции преобразуются в код. Да, чаще всего они используют визуализация в блок-схемах, но есть варианты и с yaml и с json.
Ещё было такое время, когда 1с хотели быть конструктором для бухгалтеров, где не нужны программисты. В итоге свой "язык", своя ide и огромное количество узкоспециализированных программистов со со знанием базовых бизнес логик.
Что генераторы, что 1с в итоге имеют одну основную проблему - ограниченность. И как только мы выходим за рамки тривиальных для данной системы задач - страдает скорость работы как программы, так и специалистов.
И что бы решить не тривиальную задачу, где-то рядом с ограниченной областью коржика, пишут свой быстрый бублик и иногда через жуткие костыли доставляют данные, а часто и фронт внутрь коржика. Хотя я бы не использовал такие сравнения. код - сущность не статическая во времени.
ValRakitine Автор
19.05.2024 00:03Я вот и написал статью, чтобы мы теперь могли понимать где и почему бывает, что бублики лучше коржиков.
Вот, например, есть места где бублики, вообще не катят ) иначе бы не создали методологию
https://ru.wikipedia.org/wiki/Автоматное_программирование
там дырка, вообще, запаяна наглухо ))
gev
19.05.2024 00:03Fortran, COBOL и SQL создавались с той же целью. Заменить программистов тех лет =)
Fedorkov
19.05.2024 00:03+3Вы так и не объяснили, чем плоха дырка в бублике, и зачем нужен этот VAOP. Один человеческий язык и один/несколько языков программирования закрывают все потребности процесса разработки.
В идеале заказчику не нужен будет программист. Достаточно обсудить с VAOP-copilot алгоритм или бизнес-логику, и коржик готов.
Во-первых, ИИ нужно обучать на миллионах примеров, а у вас их нет. А во-вторых, вам и заказчиков тоже придётся обучать этому языку. Проще сразу генерировать логику по аналитике на естественном языке.
WerTrtr
19.05.2024 00:03+2Нет никаких дырок в бубликах, есть плохое зрение людей. Понимание алгоритма по коду это просто вопрос опыта и знания языка, вместо того чтоб накопить знания и видеть то что нужно автор утверждает что это невозможно, поэтому можно и не пытаться. Рассуждения автора это из разряда того что для понимания текста на китайском языке, например обязательно нужен словарь и без словаря это не текст а дырка, которую мы не видим и понимаем с помощью бублика-словаря. На деле при достаточном знании языка вам не нужен бублик для понимания содержимого.
flancer
19.05.2024 00:03+2Алгоритм и код программы продолжают жить самостоятельной жизнью во всех программах-бубликах.
Мне кажется, что как дырка от бублика появляется вместе с самим бубликом, так и алгоритм появляется вместе с кодом. Говорить о том, что существует код без алгоритма, всё равно что говорить, что существует бублик без дырки. Код - это один из способов отображения алгоритма. Бывает, что в голове у программиста один алгоритм, а в коде он отобразил другой, но алгоритм всё равно есть. Алгоритм без кода существовать может, а вот код без алгоритма - нет.
panzerfaust
19.05.2024 00:03+4Напомнило потоки сознания Бугаенко и его крестовый поход в поисках правильного ООП без суффиксов -er.
ValRakitine Автор
19.05.2024 00:03Вы это хорошо подметили. Если вникнуть в идеологию методологии программирования VAOP, то можно заметить, что в ней также заложена идея чистого и ясного разделения обязанностей между компонентами системы (Action), что помогает поддерживать её в долгосрочной перспективе.
panzerfaust
19.05.2024 00:03+1идея чистого и ясного разделения обязанностей между компонентами
А существуют ли вообще идеологии погромирования, где нет идеи разделения по обязанностям или наоборот есть идея "мешайте все в кучу, б-г узнает своих"?
Если вникнуть ..., то можно заметить
Я пока только сверхценную идею заметил
Zel08
19.05.2024 00:03+1Какой бред ... Может для студента это норма, но в реале все по другому. Алгоритм - это рецепт для коржика, бублика, маффины он же кекс, а дырка от бублика это часть интерфейса, которая придает интерфейсу уникальность. Чтобы написать код мы в голове создаём алгоритм, рецепт так сказать программы, после чего приступаем к выполнению. В реальности программы это огромные, ветвистые блок схемы, если каждый начнет рисовать блок схемы, а потом каждый раз перерисовывать, так как задачи дополнялись, изменились, то программа зарастёт бюрократией и дальше схем не уйдёт, только поэтому в реальности никто не рисует блок схемы, это долго, не рентабельно, тем более вся схема в голове и ее легко переделать, ну тем более есть программы которые нарисуют блок схему в конце программы, зачем тратить и так нехватку времени. Нужен ли ИИ в вашем понимании? Нет не нужен, существует ли ИИ сегодня? Нет, его не существует, сегодня что вы называете ИИ, это ошибочное высказывание математиков.
ganqqwerty
У меня эта фраза вызвала две ассоциации. Первая - цитата из уважаемого Парнаса 1985 года:
И вторая, от авторов менее именитых, но проясняющих вопрос программирования без кода и без программиста очень наглядно:
ValRakitine Автор
Цитата "Первая - цитата из уважаемого Парнаса 1985 года:" про языки, а VAOP это методология программирования и она не про автоматическое программирование )
ganqqwerty
Ну, я не силен в коржиках и бубликах, но посмотрел на ваопы из вашей предыдущей статьи. По мне так еще один язык программирования, только зачем-то оживляющий давно упокоившиеся с миром блок-схемы и делающий из них еще менее понятные джсоны. Почему эти джсоны - не язык программирования, не код, для меня не понятно.
ValRakitine Автор
На этом простеньком примере из статьи различия особого, действительно, не видно, но при усложнении бизнес-логики и укрупненнии Actions - становиться понятно, что .json ( а в некоторых случаях и в базе данных ) записан именно Алгоритм или сценарий по которому бегает v-agent. V-agent закончил выполнение Action c некоторым Direction, определил по .json файлу (или в базе данных) следующее Action.
va-script это всего лишь некая функция, которая по текущему Action и Direction выдает на выходе следущее Action и всЁ и никакой это не язык программирования, а запись блок-схемы алгоритма. Прочитайте внимательно статью )
ganqqwerty
Блок-схема алгоритма - это уже язык программирования. Есть немало языков, которыми эти схемы можно рисовать, получая на выходе работающую программу.
gev
Надо "джсоны" заменить на s-expressions!...
Politura
Не знаю что Парнас имел ввиду под термином автоматическое программирование, но в комиксе второй чувак ловко раскрутил первого на подмену понятий. Первый наверняка изначально представлял себе вариант, когда условно менеджер вместо того, чтоб сказать программеру, что именно надо запилить, говорит это некоей машине, на том же самом языке, в свободной форме, как он делал, когда говорил с программером. То есть тот самый высокоуровневый язык это русский, или английский. И не надо прям точной спецификации, если что-то неясно - машина уточнит. Или не уточнит, и сделает нечто не то, что ожидал заказчик, ну тогда потом будут уточнения и переделки.
MountainGoat
Есть такой фреймворк, Inform7. Позволяет программировать на естественном английском языке. Им приятно пару часиков побаловаться, чтобы навсегда уяснить: в такой системе либо ты, как заказчик кода, соглашаешься на большинство действий по умолчанию, предлагаемых фреймворком; либо очень быстро получается простыня, глядя на которую ты искренне жалеешь, что не взял Python.
Fedorkov
Я бы ещё вспомнил Макконнелла.
Десятилетиями поставщики инструментария и ученые мужи обещают, что создание средств, которые позволят отказаться от программирования, не за горами. Первым и, кажется, самым забавным случаем присвоения этого ярлыка, был язык Fortran. Fortran задумывался как средство, которое даст ученым и инженерам возможность просто набирать формулы и, таким образом, обойтись без помощи программистов.
…
За последние десятилетия программисты видели массу инструментов, которые предположительно должны были устранить необходимость программирования. Сначала это были языки третьего поколения, потом — четвертого. Потом — автоматическое программирование. Потом — CASE-средства. Потом — визуальное программирование. Каждое из этих достижений привносило значительные улучшения, и общими усилиями они сделали программирование абсолютно неузнаваемым для тех, кто изучал его до этих нововведений. Но ни одна из этих инноваций не устранила программирования как такового.
Причина в том, что программирование — принципиально сложный процесс даже при наличии хорошего инструментария. Дело не в инструментах — программистам приходится бороться с несовершенством реального мира; нам нужно досконально продумывать последовательности, зависимости и исключения, иметь дело с конечными пользователями, которые никак не могут ничего решить. Нам всегда придется бороться с плохо определенными интерфейсами с другими программными и аппаратными средствам и всегда принимать во внимание инструкции, бизнес-правила и другие источники сложных проблем, возникающие вне мира программирования.
Нам всегда будут нужны люди, способные заполнить брешь между задачей реального мира, которую нужно решить, и компьютером, предназначенным для решения этой задачи. Эти люди будут называться программистами независимо от того, манипулируют они машинными регистрами на ассемблере или диалоговыми окнами в Microsoft Visual Basic. Пока у нас есть компьютеры, нам будут нужны люди, которые говорят компьютерам, чтó делать, и эта деятельность будет называться программированием.
Когда вы слышите заявления о том, что «новый инструментарий устранит необходимость компьютерного программирования», бегите! Или хотя бы посмейтесь про себя над этим наивным оптимизмом.
«Совершенный код», 2004