Комментарии 28
С комбинационным взрывом в принципе хорошо борется формализм Харела (иерархические автоматы), но там, конечно, тоже речь не идёт о «… зачастую умещается на одном экране монитора». Статья автоматный подход (и водопад впридачу — с формализованным техническим заданием и «… программа пишется только после того, как была спроектирована») всё-таки чересчур идеализирует.
Почему конечный, если в нём есть стек?
Автоматы со стеком выделяют в отдельный класс "автоматы с магазинной памятью", и на них можно решать больше классов задач, чем на конечных.
Здесь стек формально вынесен из автомата, но без него (стека) данную задачу не решить (не решить описанным образом, а вообще есть алгоритмы), и поэтому приведенный автомат фактически есть автомат с магазинной памятью.
И правда… Пора вспоминать курс теории вычислений.
Поведение автомата можно формально верифицировать, да хоть вдумчивым перебором правил автомата. Список правил анализируется проще, чем десяток-другой переплетённых if и while.
Порождения разума программиста могут содержать совершенно неочевидные ошибки, когда при сочетании 3-4 условий оказывается, что эта комбинация условий обрабатывается неправильно. Такое легко найти в логике с цикломатической сложностью выше определённого порога (где-то начиная с 10).
Стоп. Мы об описании какого-то компонента программы в виде конечного автомата или об его реализации с использованием автоматной семантики?
Компонент может быть описан как конечный автомат, но внутри состоять из кучи if/while со сложными условиями, внешними зависимостями и т. д., а может быть описан "обычно", а внутри просто дергать проверенную библиотеку, реализующую конечный автомат, передавая ей граф возможных переходов и т. п.
Не вижу смысла на одном и том же уровне абстракции описывать компонент программы одним способом, а реализовывать кардинально другим. Если в реализации получилось иначе, чем описано — нужно синхронизировать описание и реализацию во избежание множества WTF.
А на разных уровнях абстракции можно и по-разному, лишь бы документация была.
Все давно украдено до нас
В сложных системах управления конечные автоматы позволяют построить программу такой же структуры, что и управляемое устройство. В этом вся вкуснота. Автоматы позволяют не ломать голову над организацией программы (с неизбежными ошибками и архитектурными ограничениями), а просто по структуре аппаратной системы построить программную систему. Работает такая штука хорошо.
Граф никогда не формируется по коду. Наоборот, код формируется по графу. Парадигма позволяет рисовать типовые графы состояний, и генерить по ним код.
Если требования заказчика изменились, то графику придётся в любом случае менять, если Ваш проект сопровождается графикой. Если он не сопровождается графикой, тогда не придётся менять. Вопрос в сложности продукта. Если продукт сложный — без графа состояний никуда.
Тов. Шалыто, рекомендующий пихать конечные автоматы всюду, демонстрирует классическую ситуацию, когда тема диссертации заняла человека всецело.
В рамках автоматного программирования предполагается, что программа пишется только после того, как была спроектирована
Только предполагается? То есть с этим подходом всё-таки возможно писать программу без проектирования? Ненадёжное получается лекарство…
«Лекарство от болезни»: автоматное программирование