Разнообразные дела не позволили
мне своевременно информировать в рассылке
о появлении новых материалов. То, что в
результате произошло, иначе, как экспансией
автоматного программирования не назовешь.
При этом одновременно наблюдается и
разнообразие авторов. Впрочем, по порядку.
Начнем с Ханойских
башен и автоматов, в версии А.А. Шалыто,
Н.И. Туккеля и Н.Н. Шамгунова. Несколько
неожиданный "автоматный" взгляд на
проблему, определяющую в общем-то чисто
математическую постановку. Впрочем, почему
бы не построить автомат, если в программе
есть хотя бы один условный оператор? Однако,
почему автомат должен иметь больше одного
состояния? Ведь монахи, описанные в легенде,
сменяют друг друга, не оценивая то, в каком
трансе, то бишь, состоянии (и от чего)
предыдущий бедолага сдает смену. Преемнику
достаточно лишь взглянуть на результаты
проделанных трудов, чтобы приступить к
дальнейшему приближению конца света. То
есть, достаточно автомата с одним
состоянием. Другие возникшие вопросы:
почему рекурсивное решение намного проще
итеративных? Являются ли рекурсии
внутренними или концевыми? Даже немного
отвлекся на поиски соответствующих ответов.
Кое что нашел... если интересно, то ждите
статью.
В меньшей степени личный интерес
проявился к следующему автоматному
выстрелу в исполнении В.С. Любченко: задаче
об обедающих философах. В какой-то мере
это обусловлено знанием решения в
различных изложениях. К списку литературы
по теме, упомянутого автором, могу добавить
книгу В.Е. Котова "Сети Петри". Поэтому,
эквивалентное автоматное представление
особого энтузиазма не вызвало метод по
мощности эквивалентен всем прочим. Правда,
несколько насторожила "синхронная"
интерпретация асинхронных процессов.
Вместо относительной последовательности
событий, никоим образом не привязанных ко
времени, появились время, такт автоматного
времени, один автоматный такт, "пара
скачков". Начинает считаться и
учитываться то, на что в асинхронных
решениях не обращалось внимания. Впрочем,
судите сами. А мы в форуме так и не выяснили
отношения по этому поводу.
Ну и, наконец, свежий материал. "Третью
автоматную очередь всадил" А. Головешин,
любезно пополнив switch-коллекцию конвертором
из Visio в C. Таким образом, у switch-технологии
появился визуальный интерфейс. Не скажу,
что это первая попытка. Визуальное
проектирование автоматов уже было
реализовано во Флоре,
однако, почему-то, не было воспринято switch-разработчиками.
Создается впечатление, что причина в
выходных данных. Если конвертор порождает
привычный код на C, то Флора сразу начинает
выполнять графическое представление. А что
было, если бы Флора вдруг научилась
генерации кода? Представленный в
материалах подход породил мои буйные
фантазии по поводу того: можно ли, используя
Visio, строить аналогичным образом сканер или
распознаватель транслятора по диаграммам
Вирта (или другому, более простому,
представлению)? С этим и остаюсь...