Рис. 1. Автоматная и блок-схемная модели самолета-паука

SPL
Но даже на уровне отдельного процесса у моделей есть отличия, которые проецируются на язык и реализацию модели. В силу этих качеств апологеты последовательной блок-схемной модели создали конструкции языка, которые в явном или неявном виде позволяют весьма компактно ее описать. Взять тот же цикл for или хотя бы неявно подразумеваемую последовательность исполнения операторов (действия y1, y2, y3).
Для блок-схемы в одном квадратике можно без проблем перечислить действия и это не изменит последовательный характер их работы. Если же у автомата заменить переходы в состояниях s2, s3 на цикл при состоянии s1, пометив дугу этими же действиями, то смысл алгоритма изменится, т.к. введет параллелизм в его работу. Поскольку упомянутые действия должны исполнятся строго последовательно, то это и предопределило вид модели автомата (см. рис.1). Конечный автомат — модель, не допускающая «двоемыслия».
Отсутствие дискретного времени у блок-схем было их преимуществом. Но сейчас это стало их основным недостатком. Это влияет, как это не покажется кощунственным, и на образ мышления. Последовательными языками оправдывают последовательное мышление программистов, отказывая им в другом — в параллельном. Именно этим обосновывают конструкции существующего асинхронного программирования, представляя набор и функциональность операторов того же пакета asyncio. И именно этот подход, как утверждают, позволяет привычные программистам последовательные программы превратить в асинхронные (почти что параллельные).
Но вернемся к теме статьи и ее образам. Мы хотели свой «самолет» и мы его получили! Полеты или, что точнее, видимые их результаты, несколько отличаются по внешнему виду, но совершенно неотличимы по своей сути. Их можно трактовать так, что флажки подбирались и фиксировались в протоколе в ином порядке, но сами «самолеты» при этом летели, как и должно, т.е. одновременно и одновременно выбрасывали свои флажки. А уж в каком порядке их фиксировали — дело, как говорится, десятое. Главное реализовано и иполнено: последовательность и времена их сбрасывания соответствуют программе полета
Код можно сократить. Так, по-видимому, можно ограничиться кодом только одного класса. Можно скрыть и код событийного цикла. Если же при этом в исходном коде открыть подкапотный код, который сокрыт за операторами asyncio и await, то объем автоматного кода, скорее всего, уже не будет таким уж отпугивающим.
3. О проблемах реализации автоматов в Python
Остановимся подробнее на проблемах, которые породили внешний вид автоматного кода. Последний, что там скрывать, выглядит пока монструозно в сравнении с исходным кодом. Но, заметим, и первый самолет Можайского далеко не был похож на современную «сушку», да и первые автомобили отличаются далеко не в лучшую сторону от любого своего современного аналога. Подчеркну, что проблемы предъявленного автоматного кода во многом связаны с моим текущим пониманием языка Python и, возможно, в меньшей степени с возможностями самого языка.
Тем не менее первая проблема связана с языком описания автоматной модели. В С++ она решена средствами языка. В Python я таких возможностей не вижу. К сожалению, как сейчас иногда выражаются, от слова совсем. Поэтому за основу был взят метод реализации автоматов на базе управляющих операторов языка if-elif-else. Кроме того, напомним, в ВКП(а), кроме собственно автоматов, для полноценной реализации параллелизма введена теневая память и автоматные пространства. Без этого возможности автоматного программирования весьма ограничены и во многом неполноценны.
Следующая проблема, которую мы уже упоминали, — указатели. В С++ с ними проблем нет. В рамках ВКП(а) в соответствии с парадигмой ООП создан базовый автоматный класс, от которого порождаются прикладные автоматные классы, а их параметрами могут быть не только указатели, но даже их адреса. Все это позволяет просто, компактно и весьма эффективно описать и реализовать любую задачу, включающую множество параллельных взаимодействующих процессов.
Далее представлен код эквивалентных рассматриваемому примеру автоматных классов на С++. Код задержки на листинге 4 эквивалентен строке await asyncio.sleep(1) на листинге 1. В графической форме ей соответствует модель автомата FAwaitSleep на рис. 1. Такой и только такой автомат можно считать асинхронным и он не будет тормозить вычислительный поток. Автомат FSleep на этом же рисунке соответствует обычному оператору sleep(). Он проще, но гарантированно разрушит модель дискретного времени из-за действия y1, вызывающего обычную последовательную задержку. А это уже ни куда не годится.