Как нет ) , а что написано первом абзаце статьи ) One of the most tedious (but critical tasks) for software development teams is updating foundational software. It’s not new feature work, and it doesn’t feel like you’re moving the experience forward. As a result, this work is either dreaded or put off for more exciting work—or both.
Это как раз и подчеркивает важность применения алгоритмо-центричных технологий программирования, которые существенно облегчают поддержку и модернизацию софта, о чем я регулярно пишу в своих статьях.
Ваша статья показывает, что конечно-автоматный подход в программировании очень продуктивен. Я применяю его с 1981 года, и у меня он уже вылился в методологию программирования, которую я анонсировал в своей статье в 2021 году: https://habr.com/ru/articles/554014/. К сожалению, меня неправильно поняли и жестко встретили на Хабре, но несмотря на это работа над методологией успешно продолжается: https://t.me/ecoprog.
Удачи вам в ваших разработках с применением конечно-автоматного подхода.
Вот Вы пишите что ... " В отношении корутин я такой теории не знаю, хотя уже, если честно, обыскался ;) Для конечных автоматов — это теория автоматов, в которой автомат — всегда автомат в любом виде (граф, таблица, матрица и т.п.) вне связи с языком/языками программирования ... "
В Софтверной Инженерии, кроме парадигм и методологий программирования, я бы выделил еще и Миры ... В контексте софтверной инженерии, я со студентами обсуждаю интересный вопрос - а что первично Дырка или Тело бублика (алгоритм или код) Дырка порождает бублик или Тело бублика создаёт Дырку или Дырка уже до Тела бублика существовала? После чего мы переходим в обсуждению двух Миров софтверной инженерии: Алгоритмо-центричного и Кодо-центричного, по аналогии с нашим представлением, что вокруг чего вращается Солнце вокруг Земли или наоборот, Земля вращается вокруг Солнца. Очень интересно получается послушать их рассуждения на эту тему ) В v-agent oriented programming (VAOP) и в Автоматном Программировании и в model-driven engineering Алгоритмо-центричный мир и мы поддерживаем его своими методологиями, а для очень многих Солнце продолжает вращаться вокруг Земли и нет других вариантов) Вот, например, почитайте, что пишут представители кодо-центричного софтверного мира: "код и есть алгоритм. код реализует алгоритм. потому код документирует алгоритм автоматически." Вот такие ярые Кодо-центристы Джордано Бруно и сожгли )), за то, что тот сказал, что Земля не Центр Мироздания, а Алгоритм )) Лучше начать знакомство с VAOP с этой статьи на Medium: "Bagels and Muffins of Programming or How Easy It Is to Convert a Bagel into a Black Hole" или на Хабре: https://habr.com/ru/articles/814685/
Я это все к тому, что при конечно-автоматном подходе, которым автор статьи прекрасно владет мы не должны забывать, что кодим в алгоритмо-центричном софтверно-инженерном мире ... и наши программы не бублики, а коржики
Я бы к сравнению Python vs FSM добавил, что это разные Миры ...
Случайно наткнулся на вашу статью, сделав запрос в Google "конечно-автоматный подход в программировании". Я интересуюсь этой темой с 1981 года, сразу после окончания факультета Кибернетики в МИФИ. Меня там напичкали теорией о различных формальных грамматиках, но мне всегда хотелось применить конечные автоматы на практике. Весной 2021 года я опубликовал статью на Хабре с описанием моего варианта "конечно-автоматного подхода в программировании" [https://habr.com/ru/articles/554014/].
Однако сейчас я не об этом. Большое спасибо, что открыли для меня Stateflow. Надеюсь (ещё глубоко не вникал), что это поможет мне в визуализации алгоритма задачи, записанной в va-script.
"Программный агент бегает по структуре данных" - ок, вы реализовали машину Тьюринга, а ваш 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 году и хорошо понимаю, что такое машина Тьюринга и не только.
Вы это хорошо подметили. Если вникнуть в идеологию методологии программирования VAOP, то можно заметить, что в ней также заложена идея чистого и ясного разделения обязанностей между компонентами системы (Action), что помогает поддерживать её в долгосрочной перспективе.
Я вот и написал статью, чтобы мы теперь могли понимать где и почему бывает, что бублики лучше коржиков. Вот, например, есть места где бублики, вообще не катят ) иначе бы не создали методологию https://ru.wikipedia.org/wiki/Автоматное_программирование там дырка, вообще, запаяна наглухо ))
На этом простеньком примере из статьи различия особого, действительно, не видно, но при усложнении бизнес-логики и укрупненнии Actions - становиться понятно, что .json ( а в некоторых случаях и в базе данных ) записан именно Алгоритм или сценарий по которому бегает v-agent. V-agent закончил выполнение Action c некоторым Direction, определил по .json файлу (или в базе данных) следующее Action. va-script это всего лишь некая функция, которая по текущему Action и Direction выдает на выходе следущее Action и всЁ и никакой это не язык программирования, а запись блок-схемы алгоритма. Прочитайте внимательно статью )
Цитата "Первая - цитата из уважаемого Парнаса 1985 года:" про языки, а VAOP это методология программирования и она не про автоматическое программирование )
Я даже не мог предполагать три года назад, что отголоски моей первой статьи на Хабре, где я изложил основные принципы и терминологию новой методологии программирования VAOP, разойдутся так далеко. Интерес к методологии не только не угас до сих пор, но и, кажется, продолжает расти.
Применение VAOP требует от программиста понимания, что алгоритм, который он реализует в коде, существует отдельно от самого кода программы, и что в этот алгоритм можно вносить изменения. Современные программисты, начиная где-то 20-30 лет назад, стали обходить этап создания блок-схемы алгоритма, который был обязательным на заре программирования. Таким образом, для многих из них алгоритм и код программы стали восприниматься как единое целое, хотя код программы — это лишь инструкция для компьютера, написанная на языке, понятном исполнителю-компьютеру. Когда я спрашивал программистов показать мне алгоритм того, что они закодировали, они обычно указывали на код программы и пытались объяснить мне его работу, не понимая сути моего вопроса.
Вот почему, когда в своей статье я начинаю говорить об алгоритме, изобретенном "яйцеголовым", и затем описываю этот алгоритм с помощью va-script, многие не понимают, о чем идет речь. Как метко заметил мой внук: "Деда, ты пытаешься рассказать о паровозе людям, которые никогда не видели рельсов".
Вот почему, когда на первых занятиях с студентами я объясняю и демонстрирую на примерах, что алгоритм задачи, которую они должны запрограммировать, можно оформить, сохранить и редактировать отдельно от кода его реализации, они начинают осознавать все преимущества, которые предоставляет VAOP.
Затем, прочитав вместе комментарии к моей первой статье на Хабре, студенты честно признаются, что до этого момента они не полностью понимали, что такое алгоритмы и как они могут существовать отдельно. Они осознают, что va-script — это не что иное, как способ записи блок-схемы любого алгоритма, и признают, что без этого объяснения, скорее всего, также не поняли бы сути, подобно тем, кто оставлял комментарии.
Я осознаю свою долю ответственности в этом. Написав ту первую статью на Хабре, я не мог представить, что новое поколение программистов мыслит иначе, чем мы 40 лет назад. Я говорил о рельсах, стрелках и паровозах с вагонами, не учитывая изменения в восприятии. Прошу прощения, ребята. Я был не прав.
Я отвык уже от такой нетактичности или токсичности, как Вы пишите. Это неконструктивно и не практично и, главное - Зачем? устраивать на ровном месте бойцовский клуб ) Ладно. Пусть молодежь развлекается, а я попробую найти другие места для публикаций на русском языке моих работ по eco-programming парадигме и VAOP или через некоторое время вернусь, но уже в переводах
Так что будем править, постановку задачи или примеры?
Отвечая на Ваш вопрос, ничего не будем править ) Будем считать это проверкой на мнимательность чтения статьи. Я часто использую такой прмем при чтении лекций - заявляю одно, а код пишу про другое ) и смотрю на реакцию студентов ). Это типа обратной связи такой ... все уснули или не все )
VAOP подход в целом одинаков, что для ботов, что для других вещей где используют va-script (Type B) Я уже писал, что реализовал va-engine на Python для телеграм бота. Приходите в нашу группу, может, кто Вам и поможет или мне понравится Ваш бот и я его сам помогу Вам реализовать в VAOP
Считая сумму элементов Вы следовали алгоритму-сценарию, прочитанному не в va-script, а в каком-то месте, которое уже устарело. Так часто бывает. Вот и я ошибся и забыл сказать что v-agent суммирует только "comment_010":" > 0 and int and (first or third)" первый и потом каждый третий злетент при условии если они целые и положительные. При этом, очень важно, что если даже он не посчитал первый элемент отрезка потому, что он не целый и меньше нуля или ноль, то va ведет отсчет третьего элемента от этого элемента. Это к вопросу - покажите мне Алгоритм. В VAOP c этим нет проблем и разобраться и поменять при необходимости. Для сравнения попробуйте понять что и как делается в программах решающих эту задачу заказчика, написанный дедовским подходом. Там, вообще, не понять что и как складывается ) Заказчик может повеселиться и сказать, что если элемент = 0, то его не замечать и не считать первым и не вести от него отсчет каждого третьего. Вот так и играем со студентами, пока они не понимают как, вообще, раньше писали без VAOP, особено, когда я даю подправить код доугого студента на в VAOP, то первый вопрос - А что этот код делает и как? На что я отвечаю - Спроси разработчика если найдешь и если он вспомнит ) И все приходится переписывать самому с чистого листа. А это ведь лишние затраты ресурсов ...
Спасибо, что не оставили мою статью без внимания, но мне больше всего понравился один из первых комментариев от DoctorMoriarty и я его всегда, если в маразме, показываю тем, кому объясняю основы VAOP со словами - вот Вам замечательный пример короткой и жестко аргументированной оценки моей статьи. Жаль, конечно, что только очень небольшая, русскоговорящая, часть из них могут ощутить все красоту комментария от DoctorMoriarty. Пробовали на английский этот комментарий перевести, но Вы же сами понимаете что это, увы, невозможно ) Вся его красота пропадает. Эту статью, вообще, стоило написать только ради того, чтобы заслужить такой Комментарий.
В целом же, англоязычные мои слушатели перевели статью и очень внимательно через гоогл-переводчик офигевали от накала бушующих страстей в комментах, что ещё более подогревало их интерес к VAOP.
Статья, действительно ужасно непонятная и была написала не сколько с целью чтобы кто-то чего-то понял, а с целью застолбить в рускоязычном ресурсе наш российский приоритет в VAOP и застолбит новую терминологию - VA-script, VA-box и т.л. для этой совершенно новой методологии программирования
Напомню Вам, что Методология программирования — это совокупность идей, понятий, принципов, способов и средств, определяющая стиль написания, отладки и сопровождения программ.
К слову, над чем я работаю в свободное время и там else не использую. Вот в моем коде https://colab.research.google.com/drive/1X_rf3nZE9kQMSPTeXkHGK-rOyLXlBLtS?usp=sharing (!!! файл в работе. Это черновик) в VAOP tutorial в функции def getDirectionCodeDependedOfTheValueOfTheCurrentElementOfArray(va_data): хорошо видно как я без else пишу. Надо помнить что в реальных задачах с многими directions эта функция будет очень сложная и её надо, явно, без else писать Вот здесь более сложный пример по ходу лекции: (!!! файл в работе. Это черновик)
При обычном подходе (без VAOP) очень разные коды у всех получаются. Я на фрилансе нанимал программеров (алжирцев, русских, египтян, украницев, немцев ...) и просил решить эту простенькую задачу. Потом в статье покажу какой это кошмар выходит. Особенно когда просишь сделать очередной апдейт (from Update-20 to Update-30 for example) на основе чужого кода. Хотя, в жизни это почти всегда так, но они уже просили втрое больше денег, а чаще, вообще отказывались )
С самого начала, при возможности, просил вместо IF использовать SWITCH / CASE конструкции и DEFAULT, обязательно, если CASE не угадали ) Да там, вообще, много мест для борьбы на чистый код было. Унифицирование названий функций, переменных, констант. Поля в базе требовал с префиксами и заглавными буквами писать. С литералами типа == 'Yes' очень тяжело бороться. Вообще запрещал любые константы подобного типа. За семь лет проект подрастал. Приходили новые codemonkey (не знаю русского слова про таких программистов) со своим подчерком и надо было их поправлять
Как нет ) , а что написано первом абзаце статьи )
One of the most tedious (but critical tasks) for software development teams is updating foundational software. It’s not new feature work, and it doesn’t feel like you’re moving the experience forward. As a result, this work is either dreaded or put off for more exciting work—or both.
Это как раз и подчеркивает важность применения алгоритмо-центричных технологий программирования, которые существенно облегчают поддержку и модернизацию софта, о чем я регулярно пишу в своих статьях.
https://vaop.notion.site/Articles-and-useful-resources-524bcff28774477aab091b82149307eb
Ваша статья показывает, что конечно-автоматный подход в программировании очень продуктивен. Я применяю его с 1981 года, и у меня он уже вылился в методологию программирования, которую я анонсировал в своей статье в 2021 году:
https://habr.com/ru/articles/554014/.
К сожалению, меня неправильно поняли и жестко встретили на Хабре, но несмотря на это работа над методологией успешно продолжается: https://t.me/ecoprog.
Удачи вам в ваших разработках с применением конечно-автоматного подхода.
Вот Вы пишите что ... " В отношении корутин я такой теории не знаю, хотя уже, если честно, обыскался ;) Для конечных автоматов — это теория автоматов, в которой автомат — всегда автомат в любом виде (граф, таблица, матрица и т.п.) вне связи с языком/языками программирования ... "
В Софтверной Инженерии, кроме парадигм и методологий программирования, я бы выделил еще и Миры ...
В контексте софтверной инженерии, я со студентами обсуждаю интересный вопрос - а что первично Дырка или Тело бублика (алгоритм или код) Дырка порождает бублик или Тело бублика создаёт Дырку или Дырка уже до Тела бублика существовала?
После чего мы переходим в обсуждению двух Миров софтверной инженерии: Алгоритмо-центричного и Кодо-центричного, по аналогии с нашим представлением, что вокруг чего вращается Солнце вокруг Земли или наоборот, Земля вращается вокруг Солнца.
Очень интересно получается послушать их рассуждения на эту тему )
В v-agent oriented programming (VAOP) и в Автоматном Программировании и в model-driven engineering Алгоритмо-центричный мир и мы поддерживаем его своими методологиями, а для очень многих Солнце продолжает вращаться вокруг Земли и нет других вариантов) Вот, например, почитайте, что пишут представители кодо-центричного софтверного мира: "код и есть алгоритм. код реализует алгоритм. потому код документирует алгоритм автоматически."
Вот такие ярые Кодо-центристы Джордано Бруно и сожгли )), за то, что тот сказал, что Земля не Центр Мироздания, а Алгоритм )) Лучше начать знакомство с VAOP с этой статьи на Medium: "Bagels and Muffins of Programming or How Easy It Is to Convert a Bagel into a Black Hole" или на Хабре: https://habr.com/ru/articles/814685/
Я это все к тому, что при конечно-автоматном подходе, которым автор статьи прекрасно владет мы не должны забывать, что кодим в алгоритмо-центричном софтверно-инженерном мире ... и наши программы не бублики, а коржики
Я бы к сравнению Python vs FSM добавил, что это разные Миры ...
Случайно наткнулся на вашу статью, сделав запрос в Google "конечно-автоматный подход в программировании". Я интересуюсь этой темой с 1981 года, сразу после окончания факультета Кибернетики в МИФИ. Меня там напичкали теорией о различных формальных грамматиках, но мне всегда хотелось применить конечные автоматы на практике. Весной 2021 года я опубликовал статью на Хабре с описанием моего варианта "конечно-автоматного подхода в программировании" [https://habr.com/ru/articles/554014/].
Однако сейчас я не об этом. Большое спасибо, что открыли для меня Stateflow. Надеюсь (ещё глубоко не вникал), что это поможет мне в визуализации алгоритма задачи, записанной в va-script.
Вот один из самых частых случаем полного непонимания 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 году и хорошо понимаю, что такое машина Тьюринга и не только.
Вы это хорошо подметили. Если вникнуть в идеологию методологии программирования VAOP, то можно заметить, что в ней также заложена идея чистого и ясного разделения обязанностей между компонентами системы (Action), что помогает поддерживать её в долгосрочной перспективе.
Я вот и написал статью, чтобы мы теперь могли понимать где и почему бывает, что бублики лучше коржиков.
Вот, например, есть места где бублики, вообще не катят ) иначе бы не создали методологию
https://ru.wikipedia.org/wiki/Автоматное_программирование
там дырка, вообще, запаяна наглухо ))
На этом простеньком примере из статьи различия особого, действительно, не видно, но при усложнении бизнес-логики и укрупненнии Actions - становиться понятно, что .json ( а в некоторых случаях и в базе данных ) записан именно Алгоритм или сценарий по которому бегает v-agent. V-agent закончил выполнение Action c некоторым Direction, определил по .json файлу (или в базе данных) следующее Action.
va-script это всего лишь некая функция, которая по текущему Action и Direction выдает на выходе следущее Action и всЁ и никакой это не язык программирования, а запись блок-схемы алгоритма. Прочитайте внимательно статью )
Цитата "Первая - цитата из уважаемого Парнаса 1985 года:" про языки, а VAOP это методология программирования и она не про автоматическое программирование )
Я даже не мог предполагать три года назад, что отголоски моей первой статьи на Хабре, где я изложил основные принципы и терминологию новой методологии программирования VAOP, разойдутся так далеко. Интерес к методологии не только не угас до сих пор, но и, кажется, продолжает расти.
Применение VAOP требует от программиста понимания, что алгоритм, который он реализует в коде, существует отдельно от самого кода программы, и что в этот алгоритм можно вносить изменения. Современные программисты, начиная где-то 20-30 лет назад, стали обходить этап создания блок-схемы алгоритма, который был обязательным на заре программирования. Таким образом, для многих из них алгоритм и код программы стали восприниматься как единое целое, хотя код программы — это лишь инструкция для компьютера, написанная на языке, понятном исполнителю-компьютеру. Когда я спрашивал программистов показать мне алгоритм того, что они закодировали, они обычно указывали на код программы и пытались объяснить мне его работу, не понимая сути моего вопроса.
Вот почему, когда в своей статье я начинаю говорить об алгоритме, изобретенном "яйцеголовым", и затем описываю этот алгоритм с помощью va-script, многие не понимают, о чем идет речь. Как метко заметил мой внук: "Деда, ты пытаешься рассказать о паровозе людям, которые никогда не видели рельсов".
Вот почему, когда на первых занятиях с студентами я объясняю и демонстрирую на примерах, что алгоритм задачи, которую они должны запрограммировать, можно оформить, сохранить и редактировать отдельно от кода его реализации, они начинают осознавать все преимущества, которые предоставляет VAOP.
Затем, прочитав вместе комментарии к моей первой статье на Хабре, студенты честно признаются, что до этого момента они не полностью понимали, что такое алгоритмы и как они могут существовать отдельно. Они осознают, что va-script — это не что иное, как способ записи блок-схемы любого алгоритма, и признают, что без этого объяснения, скорее всего, также не поняли бы сути, подобно тем, кто оставлял комментарии.
Я осознаю свою долю ответственности в этом. Написав ту первую статью на Хабре, я не мог представить, что новое поколение программистов мыслит иначе, чем мы 40 лет назад. Я говорил о рельсах, стрелках и паровозах с вагонами, не учитывая изменения в восприятии. Прошу прощения, ребята. Я был не прав.
К счастью, в мире Идей ничего не умирает )
Я отвык уже от такой нетактичности или токсичности, как Вы пишите. Это неконструктивно и не практично и, главное - Зачем? устраивать на ровном месте бойцовский клуб )
Ладно. Пусть молодежь развлекается, а я попробую найти другие места для публикаций на русском языке моих работ по eco-programming парадигме и VAOP или через некоторое время вернусь, но уже в переводах
Отвечая на Ваш вопрос, ничего не будем править ) Будем считать это проверкой на мнимательность чтения статьи. Я часто использую такой прмем при чтении лекций - заявляю одно, а код пишу про другое ) и смотрю на реакцию студентов ). Это типа обратной связи такой ... все уснули или не все )
VAOP подход в целом одинаков, что для ботов, что для других вещей где используют va-script (Type B)
Я уже писал, что реализовал va-engine на Python для телеграм бота.
Приходите в нашу группу, может, кто Вам и поможет или мне понравится Ваш бот и я его сам помогу Вам реализовать в VAOP
Считая сумму элементов Вы следовали алгоритму-сценарию, прочитанному не в va-script, а в каком-то месте, которое уже устарело. Так часто бывает. Вот и я ошибся и забыл сказать что v-agent суммирует только "comment_010":" > 0 and int and (first or third)" первый и потом каждый третий злетент при условии если они целые и положительные. При этом, очень важно, что если даже он не посчитал первый элемент отрезка потому, что он не целый и меньше нуля или ноль, то va ведет отсчет третьего элемента от этого элемента. Это к вопросу - покажите мне Алгоритм. В VAOP c этим нет проблем и разобраться и поменять при необходимости.
Для сравнения попробуйте понять что и как делается в программах решающих эту задачу заказчика, написанный дедовским подходом. Там, вообще, не понять что и как складывается )
Заказчик может повеселиться и сказать, что если элемент = 0, то его не замечать и не считать первым и не вести от него отсчет каждого третьего.
Вот так и играем со студентами, пока они не понимают как, вообще, раньше писали без VAOP, особено, когда я даю подправить код доугого студента на в VAOP, то первый вопрос - А что этот код делает и как? На что я отвечаю - Спроси разработчика если найдешь и если он вспомнит )
И все приходится переписывать самому с чистого листа. А это ведь лишние затраты ресурсов ...
Спасибо за интересный пример применения fsm подхода Попробую реализовать его в VAOP
https://habr.com/ru/post/554014/
Спасибо, что не оставили мою статью без внимания, но мне больше всего понравился один из первых комментариев от DoctorMoriarty и я его всегда, если в маразме, показываю тем, кому объясняю основы VAOP со словами - вот Вам замечательный пример короткой и жестко аргументированной оценки моей статьи. Жаль, конечно, что только очень небольшая, русскоговорящая, часть из них могут ощутить все красоту комментария от DoctorMoriarty. Пробовали на английский этот комментарий перевести, но Вы же сами понимаете что это, увы, невозможно ) Вся его красота пропадает. Эту статью, вообще, стоило написать только ради того, чтобы заслужить такой Комментарий.
В целом же, англоязычные мои слушатели перевели статью и очень внимательно через гоогл-переводчик офигевали от накала бушующих страстей в комментах, что ещё более подогревало их интерес к VAOP.
Статья, действительно ужасно непонятная и была написала не сколько с целью чтобы кто-то чего-то понял, а с целью застолбить в рускоязычном ресурсе наш российский приоритет в VAOP и застолбит новую терминологию - VA-script, VA-box и т.л. для этой совершенно новой методологии программирования
Напомню Вам, что Методология программирования — это совокупность идей, понятий, принципов, способов и средств, определяющая стиль написания, отладки и сопровождения программ.
К слову, над чем я работаю в свободное время и там else не использую. Вот в моем коде
https://colab.research.google.com/drive/1X_rf3nZE9kQMSPTeXkHGK-rOyLXlBLtS?usp=sharing
(!!! файл в работе. Это черновик)
в VAOP tutorial в функции
def getDirectionCodeDependedOfTheValueOfTheCurrentElementOfArray(va_data):
хорошо видно как я без else пишу.
Надо помнить что в реальных задачах с многими directions эта функция будет очень сложная и её надо, явно, без else писать
Вот здесь более сложный пример по ходу лекции: (!!! файл в работе. Это черновик)
https://colab.research.google.com/drive/1_Bam5obI29R0GUWG7Pb6zUY-FeQ_KkTp?usp=sharing
При обычном подходе (без VAOP) очень разные коды у всех получаются. Я на фрилансе нанимал программеров (алжирцев, русских, египтян, украницев, немцев ...) и просил решить эту простенькую задачу. Потом в статье покажу какой это кошмар выходит. Особенно когда просишь сделать очередной апдейт (from Update-20 to Update-30 for example) на основе чужого кода. Хотя, в жизни это почти всегда так, но они уже просили втрое больше денег, а чаще, вообще отказывались )
С самого начала, при возможности, просил вместо IF использовать SWITCH / CASE конструкции и DEFAULT, обязательно, если CASE не угадали )
Да там, вообще, много мест для борьбы на чистый код было. Унифицирование названий функций, переменных, констант.
Поля в базе требовал с префиксами и заглавными буквами писать. С литералами типа == 'Yes' очень тяжело бороться. Вообще запрещал любые константы подобного типа.
За семь лет проект подрастал. Приходили новые codemonkey (не знаю русского слова про таких программистов) со своим подчерком и надо было их поправлять
Бальзам на раны. Как только я, впервые, встретил эту конструкцию:
в 1976 году в языке PL/I, то сразу понял, что это засада )
Старался всегда делать как Вы предлагаете.
Более того, сейчас 8 лет работаю в команде над проектом и за первые 3 года отучил всех искользовать ELSE.
Признаюсь, что это было не просто, но я визировал все пул реквесты и стоял на своем.