Comments 21
Вместо того, чтобы сначала рисовать блок-схемы, а потом писать код, мы сразу пишем код, который инкапсулирует алгоритм.
У меня эта фраза вызвала две ассоциации. Первая - цитата из уважаемого Парнаса 1985 года:
"automatic programming always has been a euphemism for programming with a higher-level language than was then available to the programmer. Research in automatic programming is simply research in the implementation of higher-level programming languages."
И вторая, от авторов менее именитых, но проясняющих вопрос программирования без кода и без программиста очень наглядно:
Цитата "Первая - цитата из уважаемого Парнаса 1985 года:" про языки, а VAOP это методология программирования и она не про автоматическое программирование )
Ну, я не силен в коржиках и бубликах, но посмотрел на ваопы из вашей предыдущей статьи. По мне так еще один язык программирования, только зачем-то оживляющий давно упокоившиеся с миром блок-схемы и делающий из них еще менее понятные джсоны. Почему эти джсоны - не язык программирования, не код, для меня не понятно.
На этом простеньком примере из статьи различия особого, действительно, не видно, но при усложнении бизнес-логики и укрупненнии Actions - становиться понятно, что .json ( а в некоторых случаях и в базе данных ) записан именно Алгоритм или сценарий по которому бегает v-agent. V-agent закончил выполнение Action c некоторым Direction, определил по .json файлу (или в базе данных) следующее Action.
va-script это всего лишь некая функция, которая по текущему Action и Direction выдает на выходе следущее Action и всЁ и никакой это не язык программирования, а запись блок-схемы алгоритма. Прочитайте внимательно статью )
Надо "джсоны" заменить на s-expressions!...
Не знаю что Парнас имел ввиду под термином автоматическое программирование, но в комиксе второй чувак ловко раскрутил первого на подмену понятий. Первый наверняка изначально представлял себе вариант, когда условно менеджер вместо того, чтоб сказать программеру, что именно надо запилить, говорит это некоей машине, на том же самом языке, в свободной форме, как он делал, когда говорил с программером. То есть тот самый высокоуровневый язык это русский, или английский. И не надо прям точной спецификации, если что-то неясно - машина уточнит. Или не уточнит, и сделает нечто не то, что ожидал заказчик, ну тогда потом будут уточнения и переделки.
Есть такой фреймворк, Inform7. Позволяет программировать на естественном английском языке. Им приятно пару часиков побаловаться, чтобы навсегда уяснить: в такой системе либо ты, как заказчик кода, соглашаешься на большинство действий по умолчанию, предлагаемых фреймворком; либо очень быстро получается простыня, глядя на которую ты искренне жалеешь, что не взял Python.
Я бы ещё вспомнил Макконнелла.
Десятилетиями поставщики инструментария и ученые мужи обещают, что создание средств, которые позволят отказаться от программирования, не за горами. Первым и, кажется, самым забавным случаем присвоения этого ярлыка, был язык Fortran. Fortran задумывался как средство, которое даст ученым и инженерам возможность просто набирать формулы и, таким образом, обойтись без помощи программистов.
…
За последние десятилетия программисты видели массу инструментов, которые предположительно должны были устранить необходимость программирования. Сначала это были языки третьего поколения, потом — четвертого. Потом — автоматическое программирование. Потом — CASE-средства. Потом — визуальное программирование. Каждое из этих достижений привносило значительные улучшения, и общими усилиями они сделали программирование абсолютно неузнаваемым для тех, кто изучал его до этих нововведений. Но ни одна из этих инноваций не устранила программирования как такового.
Причина в том, что программирование — принципиально сложный процесс даже при наличии хорошего инструментария. Дело не в инструментах — программистам приходится бороться с несовершенством реального мира; нам нужно досконально продумывать последовательности, зависимости и исключения, иметь дело с конечными пользователями, которые никак не могут ничего решить. Нам всегда придется бороться с плохо определенными интерфейсами с другими программными и аппаратными средствам и всегда принимать во внимание инструкции, бизнес-правила и другие источники сложных проблем, возникающие вне мира программирования.
Нам всегда будут нужны люди, способные заполнить брешь между задачей реального мира, которую нужно решить, и компьютером, предназначенным для решения этой задачи. Эти люди будут называться программистами независимо от того, манипулируют они машинными регистрами на ассемблере или диалоговыми окнами в Microsoft Visual Basic. Пока у нас есть компьютеры, нам будут нужны люди, которые говорят компьютерам, чтó делать, и эта деятельность будет называться программированием.
Когда вы слышите заявления о том, что «новый инструментарий устранит необходимость компьютерного программирования», бегите! Или хотя бы посмейтесь про себя над этим наивным оптимизмом.
«Совершенный код», 2004
А-ля подобных кодогенераторов и сейчас много. Где лоу код инструкции преобразуются в код. Да, чаще всего они используют визуализация в блок-схемах, но есть варианты и с yaml и с json.
Ещё было такое время, когда 1с хотели быть конструктором для бухгалтеров, где не нужны программисты. В итоге свой "язык", своя ide и огромное количество узкоспециализированных программистов со со знанием базовых бизнес логик.
Что генераторы, что 1с в итоге имеют одну основную проблему - ограниченность. И как только мы выходим за рамки тривиальных для данной системы задач - страдает скорость работы как программы, так и специалистов.
И что бы решить не тривиальную задачу, где-то рядом с ограниченной областью коржика, пишут свой быстрый бублик и иногда через жуткие костыли доставляют данные, а часто и фронт внутрь коржика. Хотя я бы не использовал такие сравнения. код - сущность не статическая во времени.
Я вот и написал статью, чтобы мы теперь могли понимать где и почему бывает, что бублики лучше коржиков.
Вот, например, есть места где бублики, вообще не катят ) иначе бы не создали методологию
https://ru.wikipedia.org/wiki/Автоматное_программирование
там дырка, вообще, запаяна наглухо ))
Fortran, COBOL и SQL создавались с той же целью. Заменить программистов тех лет =)
Вы так и не объяснили, чем плоха дырка в бублике, и зачем нужен этот VAOP. Один человеческий язык и один/несколько языков программирования закрывают все потребности процесса разработки.
В идеале заказчику не нужен будет программист. Достаточно обсудить с VAOP-copilot алгоритм или бизнес-логику, и коржик готов.
Во-первых, ИИ нужно обучать на миллионах примеров, а у вас их нет. А во-вторых, вам и заказчиков тоже придётся обучать этому языку. Проще сразу генерировать логику по аналитике на естественном языке.
Нет никаких дырок в бубликах, есть плохое зрение людей. Понимание алгоритма по коду это просто вопрос опыта и знания языка, вместо того чтоб накопить знания и видеть то что нужно автор утверждает что это невозможно, поэтому можно и не пытаться. Рассуждения автора это из разряда того что для понимания текста на китайском языке, например обязательно нужен словарь и без словаря это не текст а дырка, которую мы не видим и понимаем с помощью бублика-словаря. На деле при достаточном знании языка вам не нужен бублик для понимания содержимого.
Алгоритм и код программы продолжают жить самостоятельной жизнью во всех программах-бубликах.
Мне кажется, что как дырка от бублика появляется вместе с самим бубликом, так и алгоритм появляется вместе с кодом. Говорить о том, что существует код без алгоритма, всё равно что говорить, что существует бублик без дырки. Код - это один из способов отображения алгоритма. Бывает, что в голове у программиста один алгоритм, а в коде он отобразил другой, но алгоритм всё равно есть. Алгоритм без кода существовать может, а вот код без алгоритма - нет.
Напомнило потоки сознания Бугаенко и его крестовый поход в поисках правильного ООП без суффиксов -er.
Какой бред ... Может для студента это норма, но в реале все по другому. Алгоритм - это рецепт для коржика, бублика, маффины он же кекс, а дырка от бублика это часть интерфейса, которая придает интерфейсу уникальность. Чтобы написать код мы в голове создаём алгоритм, рецепт так сказать программы, после чего приступаем к выполнению. В реальности программы это огромные, ветвистые блок схемы, если каждый начнет рисовать блок схемы, а потом каждый раз перерисовывать, так как задачи дополнялись, изменились, то программа зарастёт бюрократией и дальше схем не уйдёт, только поэтому в реальности никто не рисует блок схемы, это долго, не рентабельно, тем более вся схема в голове и ее легко переделать, ну тем более есть программы которые нарисуют блок схему в конце программы, зачем тратить и так нехватку времени. Нужен ли ИИ в вашем понимании? Нет не нужен, существует ли ИИ сегодня? Нет, его не существует, сегодня что вы называете ИИ, это ошибочное высказывание математиков.
Вот один из самых частых случаем полного непонимания VAOP, а именно, va-script принимают за Код и думают, что я придумал очередной тысячный ЯП )
Вопрос выглядит так, вернее, парень задал его под видео: https://www.youtube.com/watch?v=6xzn78onzQk
"Программный агент бегает по структуре данных" - ок, вы реализовали машину Тьюринга, а ваш va-script (точнее, va-box) есть не что иное, как набор инструкций для данной машины то есть - программа. И понятное дело, что такая реализация вашего VAOP (то есть, по сути, машины Тьюринга) возможна на любом Тьюринг полном языке. Вопрос только в том - зачем она нужна? Ведь она уже реализована в любом современном процессоре, а вы своей реализацией поверх ЯП высокого уровня просто сбрасываете уровень абстракции к нулю, возвращаясь по сути к простейшим операциям перемещения по памяти и изменения состоянияния. Почитайте уже наконец какую-то литературу по теории вычислений, например книгу "Теория вычислений для программистов" или курс SiCP. И на Хабре не злые люди сидят, она вам об этом же говорили, а вы так ничего и не поняли..
Мой ответ:
Спасибо за ваш отзыв. Я хочу пояснить, что вы не совсем правы в своем утверждении: "… ваш va-script (точнее, va-box) есть не что иное, как набор инструкций для данной машины, то есть программа." Именно в этом и заключается проблема и непонимание методологии VAOP. В идеологии VAOP четко написано:
V-Agent Oriented Programming (VAOP) — это методология программирования, основанная на представлении алгоритма ( "Алгоритма" или Бизнес-логики" - я специально выделил для вас, AlexanderBorshak, это слово, а в статье https://habr.com/ru/articles/554014/ я на рисунках показываю, как блок-схема алгоритма может быть представлена как va-script и быть понятна Всем) в виде v-agent script, который позволяет программному агенту, получившему название v-agent, выполнять операции, закодированные в модулях v-agent box.
А вот здесь у меня про идеолонию методологии: Идеологически V-Agent Oriented Programming добивается того, чтобы алгоритм был записан в одном месте в виде, понятном всем — заказчикам, программистам и исполняющей среде (компьютеру). Это улучшает процесс взаимодействия всех при создании программного продукта и, что особенно важно, существенно снижает затраты на этапе поддержания работы и адаптации к изменению внешних условий в будущем.
Короче, если надо снизить затраты на этапе поддержания работы и адаптации к изменению внешних условий в будущем, или часто бизнес-логика меняется, то подумай о VAOP, а если, как обычно, сделал и забыл, то обычных методолоний хватает.
На ваш вопрос о том, зачем нужна такая реализация VAOP (по сути, машины Тьюринга) на любом Тьюринг-полном языке, отвечу: без VAOP мы получаем программу-бублик. Что такое программа-бублик, можно прочитать в моей статье по ссылке: https://habr.com/ru/articles/814685/.
Мне следовало бы назвать его не va-script, а лучше va-algorithm, так как алгоритм является моделью действий (Algorithm is a Model of Actions), по которой работает или бегает v-agent.
Не забывайте, что как и подобает методологии, она ложится на любой язык программирования. А почему? Ответ правильный — потому что она выше по уровню абстракции.
Желаю вам удачи и добавлю, что я закончил факультет Кибернетики в престижном московском высшем учебном заведении МИФИ в 1981 году и хорошо понимаю, что такое машина Тьюринга и не только.
Бублики и Коржики Программирования