Автоматное программирование, или Капля камень точит

Об авторе: Анатолий Шалыто, профессор, д.т.н., Университет ИТМО.

Восьмого сентября 2023 года мой друг во «ВКонтакте», которого я никогда не видел, Михаил Попов прислал мне такой пост в мессенджере этой сети: «Скомпоновал Ваши, Кузнецова П.Г. и Вернадского В.И идеи в метод проектирования программ под названием «Код колеса сансары, структура дхармы, ООП кармы». Есть рабочий код, концепция подходит под разные языки программирования. Интересно?»

В этом письме мне сразу показался странным перечень людей, идеи которых решил объединить автор. С идеями Вернадского и моими :-) я знаком, но всегда считал, что между ними мало точек соприкосновения. Когда же увидел в этом списке фамилию Кузнецова, то предположил, что Михаил просто спутал инициалы и написал «П.Г.» вместо «Б.П.», так как Борис Павлович Кузнецов был моим соавтором и писал об автоматном программировании. Однако я оказался неправ, так как автор поста имел в виду Побиска Георгиевича Кузнецова, «который хотел оцифровать советскую власть». Так как у меня такой цели никогда не было, нет и не будет, указанный список сильно удивил меня.

Не меньшее удивление вызвало и название предложенного метода. Однако на заданный вопрос я ответил положительно, после чего получил небольшой текст, поясняющий концепцию обучения разработке программ с использованием диаграмм состояний, которая направлена на создание, поддержание и модификация программ со сложным поведением.

В этой концепция машина состояний (граф переходов) называется «дхарма», что переводится как «то, что удерживает или поддерживает». В зависимости от контекста «дхарма» может означать «нравственные устои», «религиозный долг», «универсальный закон бытия» и т. п. Для меня автоматное программирование, которым я занимаюсь с 1991 года, это всё и есть :-)

Мне этого названия хватило, и разбираться, что Михаил в своей концепции понимает под «сансарой» и «кармой», я не стал, так как было достаточно сформулированного им утверждения: «Если разработчики будут придерживаться принципа: думай о состояниях программы и сначала измени диаграмму состояний программ, а затем код, — их ждёт труд с удовольствием и безошибочные программы!» Именно это я больше тридцати лет с некоторым успехом проповедую.

На этом наша переписка закончилась, и возобновилась только недавно – 7 ноября этого года: «Здравствуйте, уважаемый Анатолий Абрамович! Поздравляю Вас с днём Великой Октябрьской социалистической революции! В подарок шлю Вам ссылку на статью «The Coming Software Apocalypse. A small group of programmers wants to change how we code – before catastrophe strikes». By James Somers // The Atlantic. 26.09.2017. Статья подтверждает необходимость Вашего подхода к проектированию программ».

Как говорится, простенько, но со вкусом! Естественно, что мне особенно понравилось последнее предложение, а нём – слова «необходимость Вашего подхода». Приведу ссылки на два обзорно-библиографических текста об этом подходе, который некоторые считают одной из парадигм программирования: «Автоматное программирование» и «Ещё об автоматном программировании».

Вот как эта парадигма сформулирована мной: «Парадигма автоматного программирования состоит в представлении сущностей со сложным поведением в виде автоматизированных объектов управления (АОУ)» (Шалыто А.А. Парадигма автоматного программирования // Научно-технический вестник СПбГУ ИТМО. 2008. Выпуск 53. Автоматное программирование, с. 3-24). Аналоги АОУ: объекты в объектно-ориентированном программировании или агенты в агентно-ориентированном программировании.

Ссылка на текст в журнале The Atlantic и вывод, сделанный Михаилом, после его прочтения, заинтриговали меня, и я перевёл этот текст и прокомментировал его.

Конечно, семь лет, прошедших с момента выхода статьи, сначала меня несколько смутили, но потом я вспомнил слова члена-корреспондент АН СССР С.В. Яблонского: «Если наука не спекулятивна, она не устареет».

Несмотря на большое число букв в приводимом ниже тексте рекомендую его прочесть, тем более что он читается легко, так как статья публицистическая.

Автор статьи: Джорж Сомерс. Статья называется так: «Грядущий программный апокалипсис». Аннотация: «Небольшая группа программистов хочет изменить то, как мы кодируем, прежде чем произойдет катастрофа».

В ночь на 10 апреля 2014 года прошло шесть часов, когда вcё население штата Вашингтон не имело доступа к службе 911. Отключение этой службы, на тот момент крупнейшее из когда-либо зарегистрированных, было связано с программным обеспечением (ПО). Сервер, управляемый провайдером, вёл текущий счёт звонков, направленных к диспетчерам службы экстренной помощи по всей стране. Программисты провайдера установили порог, до которого может увеличиться показание счетчика.

Незадолго до полуночи счетчик превысил это число, что привело практически к общенациональному к хаосу. И поскольку программисты не предвидели эту проблему, они не ввели в систему сигналы тревоги, чтобы привлечь к ней внимание. Никто не знал, что происходит. Только утром удалось понять, что виновато ПО провайдера, и его исправление состояло в изменении всего лишь одного числа.

Не так давно до этого экстренные вызовы обрабатывались локально. Сбои были небольшими, их было легко диагностировать и устранять. Рост популярности мобильных телефонов привел к разработке более сложной системы, основанной на Интернете. В результате произошёл общенациональный сбой в работе службы 911. За несколько лет их было четыре.

В последние годы говорят, что «ПО пожирает мир». Все больше и больше критически важных систем, которые когда-то управлялись механически или людьми, начинают зависеть от кода. Так, например, летом 2015 года компания United Airlines на один день остановила свой флот из-за проблемы с системой управления вылетами; торги на Нью-Йоркской фондовой бирже были приостановлены после обновления; главная страница сайта The Wall Street Journal рухнула. Одновременный отказ стольких программных систем поначалу казался скоординированной кибератакой. Ещё более пугающим было осознание в конце дня, что это было просто совпадение.

«Когда у нас были электромеханические системы, мы могли их исчерпывающе тестировать», – говорит Нэнси Левесон (Nancy Leveson), профессор аэронавтики и астронавтики в Массачусетском технологическом институте (МТИ), которая изучала безопасность ПО в течение 35 лет. Она стала известна своим отчётом о Therac-25 – аппарате лучевой терапии, который убил шесть пациентов из-за ошибки в ПО. Она продолжает: «Раньше мы могли продумать всё, что он сможет сделать, все состояния, в которые он может попасть».

Мой комментарий. «Продумать все состояния! Это ли не первый шаг к автоматному программированию». И это всегда возможно, если мы говорим об управляющих, а не вычислительных состояниях.

Теперь снова текст переведённой статьи. Например, электромеханические блокировки, которые управляли движением поездов на железнодорожных переездах, имели ограниченное число конфигураций. На нескольких листах бумаги можно было описать всю систему и запустить физические поезда в каждой конфигурации, чтобы увидеть, как система поведёт себя. Как только она была построена и протестирована, было точно известно, с чем все имеют дело.

С ПО всё иначе. Кусок кремния с файлом может стать автопилотом или системой управления запасами. Эта гибкость – чудо ПО, и его же проклятие. Поскольку ПО легко изменить, то его постоянно меняют, а так как программа, которая в тысячу раз сложнее другой, занимает практически то же фактическое пространство, то ПО имеет тенденцию расти без ограничений.

При этом создаются системы, которые находятся за пределами способности людей управлять их поведением.

Стандартная структура размышлений об инженерных ошибках была разработана для электромеханических систем вскоре после Второй мировой войны, когда управляющее ПО ещё не использовалось. Идея состояла в том, что инженер делает что-то надёжным, создавая его части надёжными и планируя возможность поломки этих частей. Но ПО не ломается. Неисправность в ПО не похожа на неисправность механического изделия, которая приводит к крушению авиалайнера.

ПО делает именно то, что ему было предписано делать. Фактически, оно делает это идеально. Причина его отказа в том, что ему было сказано сделать что-то неправильно.

Ошибки в ПО – это ошибки понимания и воображения. В этом проблема создания чего-то с применением кода, а не физических устройств. Имеет место сложность, невидимая глазом.

Все попытки, предпринимаемые сейчас, изменить то, как создаётся ПО, похоже, начинаются с одной и той же предпосылки: код слишком сложен для размышлений. Поэтому, прежде чем пытаться понять, что люди в этом направлении пытаются предпринять, стоит понять, почему это происходит так: что в коде делает его таким чуждым для ума и таким непохожим на всё, что было до него.

Технический прогресс изменил то, как выглядел мир: можно было, например, наблюдать, как асфальтируют дороги, а сегодня едва ли можно сказать, когда что-то переделывается, потому что слишком часто это переделывается с помощью изменения ПО, чем авторы изделий с ним очень гордятся.

ПО позволило нам создать самые сложные автомобили, которые когда-либо существовали. И все же пользователи едва заметили это, потому что вся эта сложность упакована в крошечные кремниевые чипы в виде миллионов и миллионов строк кода. Но то, что мы не видим сложность, не означает, что она исчезла.

Известный ученый-компьютерщик Эдсгер Дейкстра в 1988 году писал: «Программист должен уметь мыслить в терминах концептуальных иерархий, которые гораздо глубже, чем когда-либо приходилось сталкиваться одному уму». Дейкстра высказал это как предупреждение. Поскольку программисты охотно «вливали ПО» в критические системы, они становились основой нового мира. Дейкстра считал, что программисты, возможно, переоценивают себя.

Мой комментарий. Отмечу, что задолго до этого в 1966 году он (Дейкстра Э. Взаимодействие последовательных процессов / Языки программирования. М.: Мир, 1972) предложил ввести так называемые переменные состояния, с помощью которых можно описывать состояния системы в любой момент времени. Он (как и я в автоматном программировании) использовал для этих целей целочисленные (многозначные) переменные. При этом им были поставлены вопросы о том, какие состояния должны вводиться, как много значений должны иметь переменные состояния, и что эти значения должны означать. Он предложил сначала определять набор подходящих состояний (я в автоматном программировании сделал то же), а лишь затем строить программу.

По мнению Дейкстры, диаграммы переходов между состояниями могут оказаться мощным средством для проверки программ, так как это обеспечивает поддержку его идеи о том, что программы должны быть с самого начала составлены правильно, а не отлаживаться до тех пор, пока они не станут правильными. Не появление ли автоматного программирования он предвещал?

Вернусь к переведенному тексту. Программирование по сей день для многих является таким сложным, потому что оно требует от человека думать, как компьютер. Странность этого занятия была в некотором смысле более очевидна при появлении компьютеров, когда код принимал форму нулей и единиц. Любой, кто смотрел через плечо программиста, мог увидеть, насколько отчужден программист от реальных проблем, которые пытается решить. Было невозможно сказать, рассчитывают они траектории артиллерийских снарядов или имитируют игру в крестики-нолики.

Появление языков программирования высокого уровня (ассемблер пока пропустим), таких, как Fortran и C, которые напоминают английский язык, и инструментов, известных как «интегрированные среды разработки» (IDE), которые помогают исправлять простые ошибки, затмило, хотя и мало что изменило, указанное базовое отчуждение – программист не работал над проблемой напрямую, а вместо этого проводил дни за написанием более «крупных» инструкций для машины.

Это связано с тем, что программисты часто не конца понимают проблему, которую пытаются решить, так как они слишком заняты тем, чтобы заставить свой код работать. Программисты любят использовать всевозможные инструменты для обнаружения ошибок кодирования, в то время как серьёзные проблемы, возникающие в ПО, связаны с ошибками в требованиях, а не в кодировании. Это связано с тем, что системы стали настолько сложными, что вряд ли кто-то может удержать их в голове, и использование для этого только кода не является выходом из сложившейся ситуации.

После аварии одного из автомобилей Toyota Национальное управление безопасностью дорожного движения привлекло экспертов по ПО из NASA для проведения тщательного анализа кода автомобиля. Спустя почти 10 месяцев (!) команда NASA не нашла доказательств того, что причиной аварии было ПО, но заявила, что не может доказать и обратное. На этом история не закончилась. По требованию эксперта истца команда экспертов по ПО ещё 18 месяцев (!) работала с кодом Toyota, и обнаружила очевидную вещь – он является «спагетти-кодом», для которого характерен беспорядок. Это связано с тем, что код используется и корректируется в течение многих лет разными людьми. В результате его становится невозможно отслеживать и исчерпывающе тестировать.

Из-за так спроектированного ПО у человечества могут наступить не только плохие дни, но и значительно более продолжительные промежутки времени. Проблема состоит в том, что программисты не успевают за своими собственными творениями. Анализ в качестве примера Visual Studio показал, что это более 55 миллионов строк кода, при создании которого программисты, по сути, играют с компьютером у себя в голове. Они похожи на шахматистов, играющих с завязанными глазами – тратят так много умственной энергии на то, чтобы просто представить, где находятся фигуры, и поэтому на размышления о самой игре её почти не остается.

Почему было так сложно научиться программировать? Основная проблема заключалась в том, что код очень абстрактен. Написание ПО не похоже на постройку моста, в котором все можно потрогать. Создавая программу, люди печатают слова. Когда они хотят изменить поведение программы, будь то игра, веб-сайт или имитация физической системы, они меняют не поведение, а текст программы. Некоторые учёные стали задаваться вопросом, а должно ли это быть так. Мощность компьютеров удваивается каждые 18 месяцев в течение последних 40 лет, а почему программирование при этом так мало изменилось?

Интересный доклад по этой теме был прочитан в 2012 году компьютерным исследователем Бретом Виктором (Bret Victor). Доклад называется «Изобретение на основе принципа» и стал вирусным после того, как был опубликован в Сети. В нём автор сделал два заявления. Первое – способ, которым мы создаём ПО, в корне нехорош. Второе – у него было представление, как это можно исправить.

Брет не любит писать код. «Когда я хочу что-то создать в ПО, у меня есть начальное отвращение, через которое мне приходится проталкиваться, когда я не манипулирую тем, что хочу сделать, а пишу кучу текста в редакторе. У меня есть сильное убеждение, что это неправильный способ».

В результате размышлений Брет пришел к принципу, который пронизывал всю его работу: «Необходима непосредственная связь с тем, что создаётся». Проблема в программировании состоит в том, что в нём нарушался этот принцип. Вот почему программные системы было так трудно осмысливать, и они переполнены ошибками: программист, уставившийся на страницу текста, абстрагирован от того, что он на самом деле создаёт.

Брет считает, что нынешнее представление о том, что такое компьютерная программа, появилось напрямую из Fortran и ALGOL конца 50-х годов. Эти языки были разработаны для перфокарт, и тот факт, что код на языках типа C или Java имеет форму букв на экране, не делает его менее мёртвым. Брет отмечает, что технологии развиваются быстро, а мышление людей – медленно. Поэтому легко принять новые технологии, но трудно принять новые способы мышления. Идеям, которые требуют отучиться от того, чему люди научились, и мыслить по-новому, часто оказывается огромное сопротивление.

Мой комментарий. Об этом же значительно раньше (в 1975 году) в первом издании своей книги «Мифический человеко-месяц, или как создаются программные комплексы» писал Фредерик Брукс. Интересно, что тогда он говорил, что в разработке ПО «серебряной пули» не существует, а через 25 лет – в 2010 году – в третьем издании книги в отсутствии такой пули он уже был не так уверен, потому что познакомился со статьей Дэвида Харела, упомянутой ниже, в которой описан подход к созданию ПО, близкий к автоматному программированию.

Возвращаюсь к переведённому тексту. Брет обращает внимание на аналогию разработки программы с обработкой текста. Раньше было так, что все, что можно было видеть в программе для написания документов, был сам текст, и чтобы изменить макет, шрифт или поля, приходилось писать специальные «контрольные коды» или команды, которые компьютеру, что, например, «эта часть текста должна быть выделена курсивом». Проблема была в том, что отсутствовала возможность увидеть эффект этих кодов, пока документ не был распечатан. Было трудно предсказать, что будет получено. Программисту приходилось представлять, как коды будут интерпретироваться компьютером – приходилось имитировать работу компьютера в уме.

Затем появился WYSIWYG (произносится как «визивиг», расшифровывался как «что видишь, то и получаешь»). Когда фрагмент текста помечался как курсив, буквы наклонялись прямо на экране. Если необходимо было изменить поле, можно было перетащить линейку в верхней части экрана и увидеть эффект этого изменения. Таким образом, документ стал ощущаться как нечто реальное, что можно было «потрогать» и изменить. Просто взглянув на экран, можно было понять: что-то сделано неправильно. Управление сложной системой (макетом документа и механизмом форматирования) стало доступно любому, кто мог щелкнуть на странице с помощью «мыши».

Брет считал, что программирование должно быть таким. Для него мысль о том, что люди делают важную работу, например, проектируют адаптивные системы круиз-контроля или пытаются понять рак, уставившись в текстовый редактор, была ужасна. Настоящая работа программистов – сделать так, что когда-нибудь им не пришлось это делать.

Были прецеденты, попытки понять, что это не было безумной идеей. Например, Photoshop дает мощные алгоритмы обработки изображений людям, которые, возможно, даже не знают, что такое алгоритм. Но таких примеров единицы. Реальность же состоит в том, что без написания кода в большинстве случаев не обойтись. Брет, который был в некотором роде идеалистом, видел в этом не столько возможность, сколько моральный упадок программистов в целом. Его доклад был призывом «к оружию».

В следующем докладе «Будущее программирования», сделанном через год, он сформулировал четыре вопроса, связанных с программированием по-новому.

Первый. Сегодня программа пишется в виде кода. В основном это список инструкций для компьютера. Было бы интересно путём непосредственного манипулирования структурами данных неявно создавать программу, которой должен следовать компьютер.

Второй. Сегодня для компьютера пишутся процедуры. Значительно интереснее рассказать компьютеру, чего вы хотите, а не как это делать, а компьютер «сам» решит, как это сделать. Это было названо «программированием с использованием целей».

Мой комментарий. Эту задачу могут решить «логическое программирование» (основанное, например, на языке «Пролог») и «автоматное программирование» (на любом языке программирования, включая «язык графов переходов»).

Третий. Сегодня программы пишутся, используя строки текста и текстовые файлы. Если подключить видеодисплеи к компьютерам, то всё может измениться, так как программист может начать думать о пространственном представлении информации. При этом о компьютере можно думать, как о динамичном листе бумаги, на котором многое можно представлять в таком пространстве.

Четвёртый. Сегодня программы обычно пишутся с использованием модели последовательного программирования. Однако вскоре появится параллельное аппаратное обеспечение, и программистам понадобится разумная модель параллельного программирования.

Мой комментарий. Одна из идей такого программирования состоит в отказе от потоков и их блокировок, и в переходе к выделению агентов, являющихся автоматами, которые взаимодействуют между собой путём обмена сообщениями.

Брет считает:

1. Языки программирования – это не технологии, они больше похожи на математическую нотацию, а нотации развиваются намного медленнее, чем технологии.
2. На сегодняшний день программирование больше похоже на «алхимию», когда люди наугад что-то соединяют и смотрят что получится.
3. Кризис ПО носит системный характер.
4. Знания не передаются следующему поколению автоматически.
5. В программировании абстракции развиваются с пугающей скоростью. Когда они накапливаются в достаточном количестве, понимать и контролировать всё, что происходит в сложной программе, становится невозможно.

Он также считает, что, когда создаётся что-либо программное или вносится изменение в созданную программу, необходимо сразу видеть результат. По его мнению, не может быть никакой задержки, в то же время программист обычно работает иначе: набирает кучу кода в текстовом редакторе, представляя у себя в голове, что будет делать каждая строка кода. Потом нужно компилировать и запустить программу, и только потом увидеть какой-то результат. Если что-то не так, опять приходится возвращаться к коду. Большую часть времени программист проводит, изменяя код, работая в текстовом редакторе вслепую, без мгновенной связи с тем результатом, который, на самом деле, он пытается достичь.

Можно использовать другой редактор, в котором с одной стороны расположена картинка, которая строится с помощью кода, а сам код находится с другой стороны. Этот редактор должен обеспечивать синхронизацию кода и картинки. При этом не нужно ничего компилировать и запускать. В этом случае, изменяя что-то в коде, можно увидеть изменения на картинке. Когда есть непосредственная связь между кодом и картинкой, можно подумать о способах изменения кода, отличных от набора текста…

Многое вы не сможете понять, если не видите того, что делаете. Благодаря непосредственной связи идеи и результата имеется возможность развития в направлениях, которые были до этого невозможны.

Увидев игру, сделанную Бретом так, как он говорил, слушатели доклада буквально ахнули. Они поняли, что смотрят на будущее своей отрасли. Один программист, присутствовавший на докладе, позже написал: «Внезапно все мои инструменты показались устаревшими».

Крис Грейнджер, работавший в Microsoft над Visual Studio, после просмотра видеозаписи доклада Брета был так вдохновлен, что через несколько дней после этого создал прототип новой среды программирования. Его ключевой возможностью было то, что Крис давал программисту мгновенную обратную связь с работой программы, которую тот пишет. Программист видел, что делает программа, прямо рядом с её кодом. Это было похоже на снятие повязки с глаз. Грейнджер назвал проект Light Table (Световой Стол).

Понятие жизнеспособности, возможности мгновенно видеть, как данные проходят через разрабатываемую программу, вошло в флагманские инструменты программирования, предлагаемые Google и Apple. Например, язык для создания новых приложений для iPhone и Mac, называемый Swift, был разработан Apple для поддержки среды, названной Playgrounds, которая напрямую была вдохновлена Light Table.

Увидев, какое влияние оказал его доклад, Брет был разочарован. «Все думали, что я интересуюсь программными средами, а на самом деле меня интересовало визуальное представление динамического поведения: то, как люди видят и понимают системы. Цель доклада была показать, как сделать связь между поведением системы и её кодом немедленной.

Брет предположил, что это можно сделать практически для каждой проблемы, для решения которой сегодня пишется код. Он не уверен, что программирование вообще должно существовать, по крайней мере, для разработчиков ПО. По его мнению, настоящая роль таких разработчиков должна состоять в создании инструментов, которые устраняли бы необходимость в таких разработчиках. Только тогда люди, связанные с решением самых неотложных проблем, смогут понять эти проблемы напрямую, без промежуточной ерунды, связанной с кодом.

Если внимательно посмотреть на промышленные товары, которые существуют, создаются и используются компаниями, то единственное непромышленное, что там есть – это код. Инженеры не должны разрабатывать большие системы, вводя миллионы строк кода в IDE. Единственное, что делается для автомобилей вручную – это код. Практически везде код по-прежнему остаётся ручной работой. Когда вручную создаётся 10 тысяч строк кода, это нормально, но, когда это системы, которые имеют 30 миллионов строк кода, как в Airbus, или 100 миллионов, как в Tesla – традиционное программирование становится очень и очень сложным.

В одном из эссе Брет умолял профессиональных разработчиков ПО прекратить вкладывать свой талант в инструменты для создания приложений. Неудобства повседневной жизни – это не самые важные проблемы. Им следует сосредоточиться на учёных и инженерах – их работа действительно важна и важна критически, но им приходится использовать плохие инструменты. Работа такого рода, в частности, разработка класса инструментов для «проектирования на основе моделей», ведётся уже много лет, но большинство программистов ничего об этом не знают.

Например, французская компания Esterel Technologies разрабатывает инструменты для создания критически важного для безопасности ПО. Она является одним из пионеров промышленного использования проектирования на основе моделей, при котором код напрямую не пишется. Вместо этого создаётся модель, описывающая поведение ПО, которой должна соответствовать программа, и компьютер генерирует по модели код. Если бы мы создавали систему управления лифтом, то одна из моделей описывала бы поведение его дверей. В инструменте проектирования на основе моделей модель представляется с помощью небольшой диаграммы, как будто логика рисуется на доске, в которой вершины представляют состояния двери («дверь открыта», «дверь движется» и «дверь закрыта»), а дуги определяют переходы, при которых дверь переходит из одного состояния в другое. Диаграммы делают поведение системы управления дверью наглядным. Взглянув на неё, сразу можно понять поведение двери.

Мой комментарий. О программировании лифта с использованием модели на автоматах мы писали более 20 лет назад (Наумов Л.А., Шалыто А.А. Искусство программирования лифта. Объектно-ориентированное программирование с явным выделением состояний // Информационно-управляющие системы. 2003. № 6, с. 38-49).

Продолжаю излагать перевод. Указанные инструментальные средства – это не совсем Photoshop. Его прелесть состоит в том, что изображение, которым можно манипулировать на экране, является конечным продуктом. В дизайне на основе моделей, напротив, изображение на экране больше похоже на чертёж. Тем не менее ПО, создаваемое таким образом, качественно отличается от традиционного программирования, в котором задача программиста – перевести в код так или иначе сформулированные требования к программе. Это в основном требования к её поведению. При этом бо́льшая часть энергии программиста тратится на этот перевод, а вовсе не на размышления о поведении программы. В подходе на основе моделей основное – это диаграммы. Так что именно на создание их и должно тратиться время.

Мой комментарий. И это уже будет время не программиста, а разработчика системы управления, который по этим диаграммам с помощью инструментального средства, созданного программистами, выполнит генерацию кода.

Что происходит, если модели не применять? Обычно главная проблема при создании систем управления не в навыках программистов. Они знают, как кодировать. Проблема в том, что кодировать. Обычно средства для описания того, что программа должна делать – это разговоры, словесные описания, рисунки на листе бумаги. Это слишком отличается от самого кода. Очень многое, в том числе время, теряется при переходе от такого описания к коду. Идея, лежащая в основе проектирования на основе моделей, состоит в том, чтобы исключить этот разрыв. Одна и та же модель используется как системными проектировщиками для выражения того, что они хотят, так и компьютером для автоматической генерации кода.

Конечно, чтобы этот подход был успешным, большую часть работы нужно сделать задолго до начала проекта. Сначала программисты должны создать инструмент для разработки моделей, которые будут естественны для разработчиков систем управления, и в то же время будут достаточно однозначными для понимания компьютером. Программисты должны создать программу, которая превратит эти модели в код. И, наконец, они должны доказать, что сгенерированный код всегда будет делать то, что он должен делать.

Компания Esterel Technologies, упомянутая выше, выросла из исследований, начатых в 1980-х годах во французской ядерной и аэрокосмической отраслями промышленности, которые были обеспокоены тем, что по мере усложнения критически важного для безопасности кода становится все труднее и труднее содержать его в порядке. В конце 80-х годов те, кто работал над военными системами авионики, отмечали, что число ошибок увеличивается. Это было связано с тем, что в это время число бортовых компьютеров на самолётах резко возросло. Вместо одного бортового компьютера теперь их были десятки, и каждый отвечал за узкоспециализированные задачи управления, навигации и связи. Координация этих систем для управления самолётом по мере поступления данных с датчиков и ввода команд пилотами требовала идеально синхронизированных реакций. Обработка сотен и даже тысяч событий в правильном порядке и в правильное время была определена как главная причина увеличения числа ошибок.

Стало ясно, что писать такой сложный код вручную больше нельзя. Было слишком сложно понять, что он делает, и почти невозможно проверить, правильно ли работает. Надо было что-то с этим делать, но менять инструменты в таком процессе чрезвычайно дорого. Такое решение не было бы принято, если бы создателей систем управления «не припёрли к стене».

В этой ситуации создатели авионики стали сотрудничать с учёным из французского исследовательского центра INRIA Жераром Берри (G. Berry) по созданию инструмента под названием Esterel (от французского слова «реальное время»), основой которого был одноимённый язык. Идея Esterel состояла в том, что, хотя традиционные языки программирования могут быть хороши для описания простых процедур, которые происходят в предопределённом порядке, если попытаться использовать их в системах, где события могут происходить практически в любое время и практически в любом порядке, неизбежно получался беспорядок, а он в управляющем ПО катастрофичен. При этом Берри утверждал, что методы низкоуровневого программирования не будут приемлемыми для больших программ, критически важных для безопасности, поскольку они делают понимание поведения и анализ таких программ практически невыполнимыми.

Мой комментарий. Несколько слов о нашем знакомстве с Берри. «В июне 2006 года мы провели Tutorial on Automata-Based Programming в рамках первой международной конференции International Computer Symposium in Russia (CSR 2006) (ПОМИ им. В.А. Стеклова), в котором было заслушано 24 доклада по этой тематике. Одним из докладчиков был Берри (Estrel Technology), который участвовал в разработке ПО для Airbus. В семинаре принял участие и мой старинный знакомый Михаил Кишиневский, в то время работавший в корпорации Intel, он совместно с Берри разработал текcтово-графический автоматный язык Estrel v7. Программа семинара приведена здесь. Приведу начало этой программы:

1. 1. 1. 1. Gurov V.S. (eVelopers) Automata-Based Programming Workshop organization.
         2. Shalyto A.A. (SPbSU ITMO) Automata-Based Programming.
         3. Berry G. (Esterel Technologies) Synchronous Programming Techniques for Embedded Systems.

Теперь кое-что о INRIA. 26 сентября 2018 года в 24 года наш выпускник Виталий Аксёнов защитил PhD-диссертацию в парижском Institute National de Recherche en Informatique et en Automatique (INRIA). Я присутствовал на защите, как один из руководителей и член жюри.

Вернусь к переводу. Esterel был разработан, чтобы компьютер за людей справился с этой сложностью. Это было обещанием подхода на основе моделей: вместо того, чтобы писать программный код, создавалась модель поведения системы – в данном случае модель, сосредоточенная на том, как должны обрабатываться события, как расставлять приоритеты событий, какие события зависят от других событий и т.д. Модель становится подробным планом, который компьютер будет использовать при реализации этого плана.

Почти 10 лет понадобилось, чтобы довести Esterel до использования в критически важных системах. В 2002 году появилась первая среда моделирования ПО с автоматической генерацией кода.

Мой комментарий. О языках так называемого синхронного программирования, к которым относится и Esterel, мы писали двадцать лет назад: Шопырин Д.Г., Шалыто А.А. Синхронное программирование // Информационно-управляющие системы. 2004. № 3, с. 35-42. 

Снова перевод. Сегодня семейство продуктов на базе Esterel используется во Франции для генерации кода в аэрокосмических и оборонных компаниях, на атомных электростанциях, в тяжёлой промышленности и медицинских приборах. Почти весь критически важный для безопасности код на Airbus A380 был сгенерирован автоматически. Это очень привлекательно для клиентов, особенно в авиации, так как создание высоконадёжного ПО вручную требует титанических усилий.

Разработка ПО для систем управления технологическими объектами обычно начинается с создания огромного документа с требованиями, в котором в словесной форме указано всё, что должно делать ПО. Требование может быть, например, таким: «Когда давление в этой секции поднимется выше порогового значения, откройте предохранительный клапан, если только не включен переключатель ручного управления».

Проблема с требованиями, описанными таким образом, состоит в том, что при их реализации в коде приходится кропотливо проверять, удовлетворяется ли каждое из них, а когда заказчик изменяет требования, код также должен быть изменен и тщательно протестирован, чтобы убедиться, что всё реализовано корректно. Если же по такому описанию построить модели, по которым генерируется код, то проблемы верификации и валидации резко упрощаются, в частности, по тому, что теперь изменения надо вносить не код, а в модель.

Мой комментарий. Об этом моя статья: Шалыто А.А. Валидация автоматных спецификаций // Научно-технический вестник информационных технологий, механики и оптики. 2023. № 2, с. 436-438.

Вновь перевод. Несмотря на сказанное, бо́льшая часть ПО, даже в мире авиации, одержимом безопасностью, создается традиционным способом: инженеры пишут свои требования словами, а программисты кодируют их обычно на языке программирования C. Это связано с тем, что инструменты, которые генерируют код и проверяют его правильность, не приводят в восторг программистов, так как у них отбирается контроль над программами и «хлеб».

Стандартная ситуация, связанная с прогрессом. Всякий раз, когда программирование переходило на более высокий уровень, самые громкие возражения исходили от программистов. Были большие споры по поводу перехода от «языка низкого уровня», максимально приближенного к единицам и нулям, к «языку ассемблера». Люди, писавшие программы на языке низкого уровня, с криком боролись за то, чтобы сохранить его. И аргументы были настолько похожи на сегодняшние: «Откуда мы знаем, что язык ассемблера сделает это правильно?»

Об этом же Брет рассказывает на указанной выше лекции 2013 года: «Ребятам, которые писали в двоичном коде, в 1947 году показали ассемблер, но он их не заинтересовал. Они не видели никакой ценности в нём. Таким образом, может появиться большое сопротивление новым способам работы, которые требуют от Вас как бы отучиться от того, что Вы уже изучили, и думать по-новому, что весьма трудно. При этом даже может возникнуть прямая вражда. Примечательно, что великий фон Нейман говорил: «Я не понимаю, зачем кому-то понадобится что-либо кроме машинного кода».

Та же история повторилась чуть позже, когда под руководством Джона Бэкуса (John Backus) в 1957 году был разработан язык высокого уровня Fortran, который позволял писать формулы, как будто в математической нотации, а также наглядно описывать циклы. Он был показан программистам на ассемблере, но не вызвал у них интереса. Они не увидели в нём никакой ценности».

Поэтому не удивительно, что «люди нелегко переходят на разработку ПО на основе моделей: они воспринимают это, как еще одну возможность потерять контроль, и даже больше, чем они уже потеряли».

Предубеждение против проектирования на основе моделей, которое называют также инженерией на основе моделей (MDE), на самом деле настолько укоренилось, что некоторые даже утверждают, что существует более сильная потребность в изучении восприятия MDE людьми, чем в исследовании новых технологий, используемых в MDE.

Это звучит почти как шутка, но для сторонников подхода на основе моделей это важный момент: они знают, как сделать сложное ПО надёжным, но во многих местах они по указанной причине предпочитают этого не делать. При этом получающиеся продукты считаются огромными достижениями, но только их авторы знают, что глубоко в конструкциях этих продуктов зарыты возможные катастрофы, ожидающие своего часа. Человеческая интуиция плохо справляется с оценкой истинной вероятности якобы «чрезвычайно редких» комбинаций событий в системах, работающих в масштабе огромного числа запросов. Эта человеческая склонность к ошибкам означает, что некоторые из наиболее тонких и опасных ошибок оказываются ошибками в дизайне. Код добросовестно реализует предлагаемый дизайн, но дизайн-то может не учитывать необходимости реализации «редких» сценариев.

Алгоритмы, лежащие в основе действительно критических систем, должны быть не просто хорошими, а практически идеальными. Одна ошибка может оказаться катастрофической. Но известно, как трудно найти ошибки, особенно по мере усложнения алгоритма. Вы можете провести столько тестов, сколько захотите, и никогда не обнаружите все ошибки.

Для дополнительной борьбы с ошибками стали применять верификацию. Однажды одному руководителю проекта создания критически важного ПО в статье попалась странная смесь математики и кода (или того, что выглядело как код), которая описывала алгоритм на чём-то под названием TLA+, что означает Temporal Logic of Actions + Data (Временна́я Логика Действий + Данные).

Этот язык предназначен для записи требований к компьютерным программам. Требования к программам на этом языке называют «спецификациями». Они могут быть проверены компьютером. При этом прежде, чем пишется или генерируется код, на этом языке описывается логика программы вместе с ограничениями, которым она должна соответствовать (например, если программируется банкомат, ограничением может быть то, что никогда нельзя дважды снять одни и те же деньги со своего текущего счета). Затем инструментальное средство для поддержки TLA+ тщательно проверяет, что логика анализируемой программы действительно удовлетворяет этим ограничениям. Если не удовлетворяет, то средство указывает, как именно эти ограничения могут быть нарушены.

По мнению Лесли Лэмпорта (Leslie Lamport) – автора языка TLA+, главная причина, по которой современное ПО содержит много ошибок, состоит в том, что программисты сразу переходят к написанию кода. Архитекторы в строительстве зданий рисуют подробные планы до того, как будет положен первый кирпич или забит первый гвоздь. Однако только немногие программисты пишут даже грубый набросок того, что будут делать их программы, прежде чем начнут кодировать (примечание редактора: вот она, настоящая стабильность – ровно теми же словами советские инженеры военного НИИ без малого полвека назад журили разработчиков ПО, предпочитавших работать не над проблемой, а по ТЗ). Программистов привлекает рутина кодирования, потому что код – это то, что работает. Трата времени на что-то ещё кажется им недопустимым.

Интересно, что и Лэмпорт считает, что код никогда не предназначался для того, чтобы быть средством для размышлений, так как он ограничивает способность человека думать, если раздумья проходят в терминах языка программирования. При использовании только такого формализма, как код, за деревьями не удаётся увидеть леса: программа привлекает внимание к работе её компонент, а не к тому, что она должна делать, и определению того, делает ли она то, на что программист надеялся.

Поэтому Лэмпорт создал TLA+. Как и в случае с проектированием на основе моделей, TLA+ фокусируется на высокоуровневой структуре системы и её основной логике, а не на коде, который их реализует.

TLA+ занимает лишь небольшой, дальний угол мейнстрима, если можно так сказать, что он вообще занимает там место. По мнению Лэмпорта, это связано с провалом в образовании. Хотя программирование родилось в связи с математикой, но с тех пор значительно отдалилось от неё. Большинство программистов не владеют той математикой, которая нужна для работы с TLA+. Очень немногие программисты (и в том числе очень немногие преподаватели программирования) понимают основные концепции TLA+ и то, как они применяются на практике. Эти программисты, похоже, думают, как фон Нейман :-): «Всё что им нужно – только код». Идея о том, что есть некий более высокий уровень абстракции, чем код, на котором можно уметь точно мыслить, и что математика на самом деле позволяет точно мыслить об этом, им совершенно чужда. Потому что они никогда этому не учились».
Но не все специалисты в области разработки ПО согласны с тем, что в этом виноваты только программисты, которые боятся математики. На самом деле они не знают или не верят, что математика может помочь им справиться со сложностью программ. Сложность – самая большая проблема для программистов. Указанные специалисты считают, что настоящая проблема состоит в том, чтобы убедить программистов, которые по природе очень прагматичны, что это не будет пустой тратой их времени.

Применение традиционного программирования – совершенно нормально до тех пор, пока не возникает реальная проблема сложности. В ПО автомобилей много ошибок. Положение с ним в этой области не похоже на авионику, в которой к его качеству относятся очень серьёзно. Там признано, что ПО отличается от механики, что не доходит до многих создателей современных автомобилей. Они ещё не осознали, что на самом деле занимаются программным бизнесом. В беспилотных автомобилях ПО должно быть практически идеальным, а это непростая задача, так как вычисления по своей сути невидимы. Когда шины у автомобиля спущены, это видно. Когда сломано ПО, ничего не видно, и в этом большая проблема.

На этом переведённая статья закончилась. Приведу ссылку на первую работу Лэмпорта по обсуждённой тематике: Lamport L. The Temporal Logic of Actions // ACM Transactions on Programming Languages and Systems. V. 16. 1994. Issue 3, pp. 872-892.  Эта работа была выполнена в корпорации DEC, которая уже давно не существует. Статья на 12 ноября 2024 года цитировалось 3146 раз, что не много для классика и 30-ти лет с момента её публикации. Это свидетельствует о том, что эта тематика весьма далека от программистского сообщества.

Ещё хуже по цитируемости дело обстоит с его книгой под названием «Specifying Systems. The TLA+ Language and Tools for Hardware and Software Engineers», опубликованной в 2002 году. В это время её автор уже работал в Microsoft Research. На указанную выше дату книга цитировалась ещё меньше, чем его классическая статья – 2004 раза. Книга имеет такой эпиграф: «Эта книга – всего лишь черновик, нет, всего лишь черновик черновика».

Несколько слов о ней. «Эта книга показывает, как писать недвусмысленные спецификации сложных компьютерных систем. Её первая часть представляет собой введение, объясняющее, как с математической точностью описывать поведенческие свойства системы. Акцент делается на свойствах безопасности. Вторая часть охватывает более сложные темы, такие как жизнеспособность, свойства реального времени и т. д. Последние две части книги представляют полное справочное руководство по языку и инструментам TLA+. Этот язык разработан автором для написания простых и элегантных спецификаций поведения систем и протоколов, а также для проверки правильности проекта. Язык доказал свою ценность в понимании и построении параллельных и распределённых систем. Инструменты для синтаксического анализа TLA+ и проверки моделей доступны бесплатно в Интернете.

За год до выхода этой книги была опубликована статья Batson В., Lamport L. High-Level Specifications: Lessons from Industry, в которой рассказано о том, как Batson использовал «это» в корпорации Intel. Он считал, что TLA+ представляет собой единственную эффективную методологию, которую он видел для визуализации и количественной оценки алгоритмической сложности способом, который имеет смысл для инженеров.

Перечень работ Лэмпорта приведён здесь.

Мой комментарий. Мы занимались верификацией автоматных программ с 2006 года (Вельдер С.Э., Шалыто А.А. Введение в верификацию автоматных программ на основе метода Model Checking. 2006, 52 с.; Вельдер С.Э., Шалыто А.А. О верификации простых автоматных программ на основе метода Model Checking // Информационно-управляющие системы. 2007. № 3, с. 27-38). В 2011 году мы в издательстве «Наука» опубликовали книгу: Вельдер С.Э., Лукин М.А., Шалыто А.А., Яминов Б.Р. Верификация автоматных программ. СПб.: Наука. 2011. 242 с. В книге рассмотрены другие логики и их применение: линейная темпоральная логика (LTL), ветвящаяся темпоральная логика (CTL) и темпоральная логика реального времени (TCTL). В книге, в частности, приводится пример верификации одного из требований, предъявляемых к ПО банкомата (с. 184-188), о котором упомянуто выше.

К сожалению, методы верификации, которые мы использовали, не гарантируют безошибочности программы: так же, как при тестировании программы неизвестно, сколько надо иметь тестов для того, чтобы быть более не менее уверенным в её правильности, так же непонятно, сколько надо иметь темпоральных требований, которые надо проверять при верификации. Об этом статья: Ульянцев В.И., Шалыто А.А. О верификации простых программ со сложным поведением.

В том же направлении, что и мы, работали Е.В. Кузьмин и В.А. Соколов, которые в статье Моделирование, спецификация и верификация «автоматных» программ // Программирование. 2008. № 1, с. 38-60 несколько раз ссылаются на нас.

Книг по верификации программ на русском языке становится всё больше: Карпов Ю.Г. Model Checking. Верификация параллельных и распределенных систем. СПб.: БХВ-Петербург. 2010. 560 с.; Камкин А.С. Введение в формальные методы верификации программ. Учебное пособие. М.: МАКС Пресс. 2018. 272 c.; Миронов А.М. Методы верификации программ. М.: ДМК Пресс. 2023. 336 c.; Рустан К., Лейно М. Доказательство корректности программ. М.: ДМК Пресс. 2024. 530 c. Поэтому можно надеяться, что со временем эти методы будут более широко использоваться на практике.

Несколько слов о спецификациях в автоматном программировании. Это система взаимосвязанных (в том числе и иерархических) графов переходов. При этом она может быть формально и изоморфно реализована на различных языках программирования, как это описано в моей книге о Switch-технологии, которая упомянута ниже. Однако наибольший кайф можно получить, когда языки спецификации и программирования совпадают – имеет место исполняемая спецификация, как, например, это имеет место при использовании инструментального средства StateFlow, применение которого изложено в упомянутых ниже моих работах с Ю.Ю. Янкиным. Автоматные программы по построению обычно содержат меньше ошибок, чем написанные традиционно. Их качество может быть повышено, если проверку поведения системы проводить не по системе взаимосвязанных автоматов, а по одному автомату, эквивалентному этой системе.

Переходим к весьма длинному заключению.

Когда люди где-либо в тексте используют скобки, то, кроме открывающей должна быть ещё и закрывающая скобка. Применительно к этому тексту открывающей скобкой можно назвать пост в мессенджере сети «ВКонтакте» Михаила Попова, который приведён в начале текста. Когда я заканчивал писать его, неожиданно «возникла» закрывающаяся скобка: пост о концепции обучения с использованием автоматов, но этот раз – детей. Об этом в том же мессенджере написал мне наш выпускник 2005 (!) года Сергей Михайлов, которого я практически не видел со дня его окончания института: «Добрый день, Анатолий Абрамович! Наткнулся на свежую обучающую платформу по событийному программированию для школьников. Это всё называется «ПРИМС» (Программирование Расширенных Иерархических Машин Состояний). Они даже сделали серию игр («Берлога»), где «боты» программируются с использованием конечных автоматов. В их «методичке» в списке литературы присутствуют три Ваших работы, но они пишут, что она является переводом другой методички (на этот раз иностранной)». После этого Сергей привёл две ссылки.

Зашел по первой ссылке и увидел сайт, названный авторами «Берлога», на котором было пояснение, радующее мою душу, так как вчерне знал о чём по сути идёт речь: «Национальная киберфизическая платформа», на которой осуществляется обучение программированию через игры. Новый подход к урокам информатики, где азам программирования можно научиться прямо в игре.

Там же написано: «Программирование расширенных иерархических машин состояний (ПРИМС). Этот новый инструмент обучения адаптирован для начинающих пользователей, который позволяет школьникам не только изучать основы программирования, но и формировать мышление, необходимое программисту в реальных промышленных и технологических проектах». Неплохо сказано – как будто написал я…

После этого обратился ко второй ссылке. И прочитал следующее: «Основы событийного программирования и программирования расширенных иерархических машин состояний. В работе представлено краткое и доступное для начинающих введение в современную технологию разработки систем управления. Данная технология основана на создании и применении расширенных иерархических машин состояний, использующих методы событийного программирования. Работа в значительной степени опирается на публикации Miro Samek, в том числе, на краткое руководство по машинам состояний UML: «A Crash Course in UML State Machines», расширяя и дополняя его, а также адаптируя текст для восприятия начинающих».

После этого с этой странице я скачал пособие: Воеводина А.И., Воеводин И.Г., Цырульников Е.С., Шумак К.А. Основы событийного программирования и программирования расширенных иерархических машин состояний (ПРИМС). Ассоциация участников технологических кружков. Национальная киберфизическая платформа. Астрахань, Москва, Уфа. 2024. 63 с.

В первой главе «Основы машины состояний» снова сказано: «В настоящей работе представлено краткое и доступное для начинающих введение в современную и перспективную технологию разработки систем управления. Эта технология основана на создании и применении расширенных иерархических машин состояний, использующих методы событийного программирования. Эта публикация в значительной степени основана на работах Miro Samek [1, 2] в том числе, на краткое руководство по машинам состояний UML – «A Crash Course in UML State Machines», расширяя и дополняя его, а также адаптируя его для начинающих».

Мой комментарий. Слова «современную» и «перспективную», использованные выше, мне очень понравились, так как считаю, что они применимы не только к ChatGPT, а также ко всему тому, что полезно, но по каким-то причинам в настоящее время мало используется, тем более что по словам Аристотеля «даже известное известно немногим».

Продолжу изложение пособия: «Читателю также будет интересен опыт отечественных специалистов, в течение последних лет занимающихся аналогичным подходом в программировании, практическим использованием его в создании систем управления. Машины состояний представляют собой разновидность конечных автоматов – математической концепции, нашедшей практическое применение в программировании. Одним из наиболее в известных российских ученых, внёсших большой вклад в развитие автоматного подхода в программировании, является А.А. Шалыто [3-5]. Его основной разработкой является SWITCH-технология, основанная на программной реализации графов переходов автоматов систем управления».

Мой комментарий. Интересно, 1991 год, когда я стал использовать автоматы в программировании и писать про это, тоже относится к последнему времени?

Несколько слов из мира науки :-) Прочитал фразу: «Свидетельство ненормальности – повторение одного и того же поступка с ожиданием разных результатов». Потом прочёл еще где-то: «Самая большая глупость – делать то же самое и на надеяться на другой результат». Хотел бы поверить в это, но конечные автоматы, которыми я занимаюсь уже много лет, при повторении одних и тех же входных воздействий могут формировать разные результаты.

Теперь приведу ссылки, публикации на отмеченные авторами методички:

1. Samek M. Practical UML Statecharts in C/C++. Second Edition. Event-Driven Programming for Embedded Systems. CMP Books. 2009. 712 p. https://www.state-machine.com/doc/PSiCC2.pdf
2. Application Note. A Crash Course in UML State Machines (Примечание по применению. Ускоренный курс по конечным автоматам UML). Quantum Leaps https://www.state-machine.com/). 2015. 30 p. https://www.state-machine.com/doc/AN_Crash_Course_in_UML_State_Machines.pdf
3. Канжелев С.Ю., Шалыто А.А. Автоматическая генерация автоматного кода // Информационно-управляющие системы. 2006. № 6, с. 35-42. http://i-us.ru/index.php/ius/article/view/14568
4. Шалыто А.А. Switch-технология. Алгоритмизация и программирование задач логического управления. СПб.: Наука. 1998, 628 c. http://is.ifmo.ru/books/switch/1
5. Шалыто А.А. Логическое управление. Методы аппаратной и программной реализации алгоритмов. СПб.: Наука. 2000, 780 с. http://is.ifmo.ru/books/log_upr/1

Укажу ещё несколько ссылок на важные работы по этой тематике:

1. Harel D. Statecharts: a Visual Formalism for Complex Systems // Science of Computer Programming. V. 8. 1987. Issue 3, pp. 231-274. https://www.sciencedirect.com/science/article/pii/0167642387900359
2. Samek M. Practical Statecharts in C/C++: Quantum Programming for Embedded Systems. CMP Books, 2002. 387 p. https://www.state-machine.com/doc/PSiCC.pdf
3. Shalyto A.A. Software Automation Design: Algorithmization and Programming of Problems of Logical Control // Journal of Computer and System Sciences International. 2000. Vol. 39. No 6, pp. 899-916. http://is.ifmo.ru/articles_en/2000/shalyto-switch-2000.pdf (Шалыто А.А. Автоматное проектирование программ. Алгоритмизация и программирование задач логического управления // Известия РАН. Теория и системы управления. 2000. № 6, с. 63-81. https://www.avrorasystems.com/ru/Data/Pressroom/Files/ran.pdf).
4. Shalyto A.A. Logic Control and «Reactive» Systems: Algorithmization and Programming // Automation and Remote Control. 2001. Vol. 62. No 1, pp. 1-29. http://is.ifmo.ru/articles_en/_log_control.pdf (Шалыто А.А. Алгоритмизация и программирование для систем логического управления и «реактивных» систем // Автоматика и телемеханика. 2001. № 1, с. 3-39. https://www.mathnet.ru/links/55ca95bd9025c22c9379f590b7843122/at1715.pdf).
5. Wagner F., Schmuki R., Wagner T., Wolstenholme P. Modeling Software with Finite State Machines. A Practical Approach. Auerbach Publications. 2006, 362 p. https://is.ifmo.ru/download/modelingsoftwarewithfinitestatemachinesapracticalapproach.pdf
6. Поликарпова Н.И., Шалыто А.А. Автоматное программирование. Рукопись книги для издательства «Питер». 2008, 168 с. http://is.ifmo.ru/books/_book.pdf
7. Вельдер С.Э., Лукин М.А., Шалыто А.А., Яминов Б.Р. Верификация автоматных программ. СПб.: Наука. 2011. 242 с. http://is.ifmo.ru/verification/velder_verification_posobie_nauka.pdf
8. Янкин Ю.Ю., Шалыто А.А. Автоматное программирование ПЛИС в задачах управления электроприводом // Информационно-управляющие системы. 2011. № 1, с. 50-56. http://i-us.ru/index.php/ius/article/view/13825
9. Янкин Ю.Ю., А.А. Шалыто А.А. Метод создания ПО на основе программируемых логических интегральных схем. Видеоприложение. 2022. https://www.youtube.com/watch?v=YNWdmnwHZi8

После этого я ответил Сергею: «Спасибо огромное. Знал бы, как это мне сейчас «в дугу» – пишу большой текст практически по этой же теме, и вдруг такая ссылка! Как ты её нашел? Случайно? Кто-то подсказал?»

Он ответил: «В школе попросили детей поучаствовать в турнире по этой игре. Начал разбираться. Разыскал документацию и на всякий случай заглянул в список литературы :). Насколько я понял, вас там упоминают в первой главе как «одного из выдающихся российских учёных в области автоматного программирования!»

Приведу мой ответ: «И правильно делают, так как я в этой области практически один. Но они этот термин не используют: видимо, не добрались до моей с Надей Поликарповой книги «Автоматное программирование», изданной в издательстве «Питер» ещё в 2009 году, и моих статей. Но скорее всего до неё доберутся – какие их годы! А если без шуток, то в этой области исследования проводят лишь мой давний знакомый Федор Александрович Новиков, который, например в статье «Кооперативное взаимодействие автоматных объектов» // Информационно-управляющие системы. 2016. № 6, с. 50-64  признал мой вклад в развитие и продвижение этого подхода, а также Владимир Иванович Шелехов, который в частности, опубликовал статью «Язык и технология автоматного программирования», где пишет, что концепция автоматного программирования разработана Анатолем Шалыто. Наконец-то не только Куракин из «Войны и мира», но и я стал Анатолем!

После этого я обратил внимание Сергея на очень важный факт: «Многие и авторы «Берлоги» тоже, предлагая методику для начинающих, используют сложную инфографику, которая всё запутывает и усложняет.

Как просто и правильно без всякой дурацкой инфографики на автоматах делать игры с вашей помощью было отработано ещё когда ты учился: в 2003-2005 годах. По этому адресу приведён ряд программно-реализованных проектов игр и систем управления, которые содержат как один автомат, так и иерархическую систему взаимодействующих автоматов. Если сможешь, расскажи об этом тем, кто озадачил в этом направлении детей, и попроси их сообщить об этом создателям предлагаемого подхода к обучению начинающих! То, что они работают в этом направлении – здорово, но, если подход переусложнен, как это сделано ими, то никто и нигде без их присмотра использовать его не будет».

Введение инфографики может быть оправдано якобы благой целью – для «упрощения» понимания начинающими, и материальным благом для авторов разработки, так как предлагаемый подход должен чем-то отличаться от подхода, предложенного в указанном выше Application Note от компании Quantum Leaps.

Такую же помощь также для упрощения жизни начинающим за счёт введения дополнительной инфографики в свое время предлагали во всемирно известном программируемом конструкторе Lego Mindstorms. Мы ещё в 2005 году разрабатывали ПО на основе автоматного подхода для этих роботов без применения инфографики  о чем в 2011 году я прилюдно сообщил российским дистрибьютерам этого продукта, которые рассказывали, как этой мутью пользоваться. Кстати, специалисты по разработке ПО, которые были на этой презентации, проходившей в рамках соревнования Russian Code Cup, организованного компанией Mail.Ru и университетом ИТМО, поддержали меня. Однако моё предложение вряд ли стало известно разработчикам Lego Mindstorms.

В этом месте можно констатировать, что автоматное программирование оказалось в виртуальных скобках, а этот текст подтверждает известное выражение о том, что капля камень точит…

В заключение совет от Джефри Хинтона, получившего в 2024 году Нобелевскую премию за разработку глубоких нейронных сетей, что было движением поперек направления, принятого в своё время в искусственном интеллекте: «Ищите место, где по Вашему мнению все делают что-то неправильно, и доверяйте своей интуиции. Пока Вы не поймете, что Ваша интуиция почему-то неверна, доверяйте ей и работайте над альтернативными способами решения поставленной Вами задачи».

Я всё ещё доверяю своей интуиции, и поэтому написал этот текст.