How to become an author
Search
Write a publication
Pull to refresh

Comments 28

Можете более широко раскрыть вопрос границ применимости и неприменимости парадигмы автоматного программирования?
Total votes 1: ↑1 and ↓0+1
Подозреваю, тут как и с применимостью логики для решения любых математических задач. Вроде бы и да, но нет. Потому что комбинаторный взрыв при сложности отличной от hello_world.
Total votes 3: ↑3 and ↓0+3

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

This comment wasn’t rated yet0
Как понимаю это паттерн машина состояний?
Total votes 2: ↑2 and ↓0+2
Насколько я знаю, используется на ура в embedded-системах. Правда, не совсем понятно, при чем тут уважаемый ИТМО и проблемы с софтом на атомных станциях: если документацию похерили, то не все ли равно, на какой парадигме был основан исходник? Проблема явно в процессе, а не в том, как веселее описать алгоритм.
Total votes 4: ↑4 and ↓0+4

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


Здесь стек формально вынесен из автомата, но без него (стека) данную задачу не решить (не решить описанным образом, а вообще есть алгоритмы), и поэтому приведенный автомат фактически есть автомат с магазинной памятью.

Total votes 4: ↑2 and ↓20
Автомат с магазинной памятью — это разновидность конечного автомата (вики). Конечность у автоматов заключается в ограниченном множестве состояний.
Total votes 4: ↑4 and ↓0+4

И правда… Пора вспоминать курс теории вычислений.

This comment wasn’t rated yet0
В вики не так написано. Скорее уж, конечный автомат — это разновидность МП-автомата, с доп. ограничениями.
Total votes 2: ↑0 and ↓2-2
Это ересь. Термин «конечный автомат» не соотносится к какому-то конкретному автомату, тем более — как вы считаете — какому-то самому простому из них. В качестве контрпримера предлагаю Вам напрямую (без конверсии) получить недетерминированный автомат из Вашего понимания конечных автоматов как частного случая МП-автоматов.
Total votes 1: ↑1 and ↓0+1
Термин «конечный автомат» не соотносится к какому-то конкретному автомату, тем более — как вы считаете — какому-то самому простому из них.
Тогда укажите, какой, по-вашему, самый простой автомат должен стоять в конце иерархии Хомского:
1. КЗ-языки
2. КС-языки — МП-автоматы
3. регулярные языки — ?
This comment wasn’t rated yet0
Как мне кажется, при каждом изменении требований заказчика понадобится формировать новый граф состояний и фактически переписывать реализацию.
This comment wasn’t rated yet0
Если граф формируется по коду, то только реализацию.
This comment wasn’t rated yet0
В 1991-м был ЛИТМО. А по теме — не очень ясно чем автоматы лучше других способов при равной степени документации. До важных проектов прежде всего нужна подробная документация и хорошие тесты, в том числе нефункциональные. А автоматы, функции, обычные объекты, да хоть скрипты на брэйнфаке — дело десятое.
Total votes 3: ↑3 and ↓0+3

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


Порождения разума программиста могут содержать совершенно неочевидные ошибки, когда при сочетании 3-4 условий оказывается, что эта комбинация условий обрабатывается неправильно. Такое легко найти в логике с цикломатической сложностью выше определённого порога (где-то начиная с 10).

Total votes 1: ↑1 and ↓0+1

Стоп. Мы об описании какого-то компонента программы в виде конечного автомата или об его реализации с использованием автоматной семантики?


Компонент может быть описан как конечный автомат, но внутри состоять из кучи if/while со сложными условиями, внешними зависимостями и т. д., а может быть описан "обычно", а внутри просто дергать проверенную библиотеку, реализующую конечный автомат, передавая ей граф возможных переходов и т. п.

Total votes 1: ↑1 and ↓0+1

Не вижу смысла на одном и том же уровне абстракции описывать компонент программы одним способом, а реализовывать кардинально другим. Если в реализации получилось иначе, чем описано — нужно синхронизировать описание и реализацию во избежание множества WTF.
А на разных уровнях абстракции можно и по-разному, лишь бы документация была.

This comment wasn’t rated yet0

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

This comment wasn’t rated yet0
UFO just landed and posted this here

Формальная верификация ещё в Ada 83 была.

This comment wasn’t rated yet0
Хмм… Простите, конечно, но суть технологии раскрыта слабовато, т.к. обход дерева не раскрывает всей мощи автоматного программирования. А вот АЭС вполне можно запрограммировать набором конечных автоматов. Но и неавтоматные подсистемы будут нужны. Вообще говоря «автоматное программирование» к документации не имеет отношения. «Конечные автоматы», «машина состояний» — это парадигма построения алгоритма управления. А документация — это уже детали продукта. Документация может быть или не быть для любой парадигмы.
В сложных системах управления конечные автоматы позволяют построить программу такой же структуры, что и управляемое устройство. В этом вся вкуснота. Автоматы позволяют не ломать голову над организацией программы (с неизбежными ошибками и архитектурными ограничениями), а просто по структуре аппаратной системы построить программную систему. Работает такая штука хорошо.
Граф никогда не формируется по коду. Наоборот, код формируется по графу. Парадигма позволяет рисовать типовые графы состояний, и генерить по ним код.
Если требования заказчика изменились, то графику придётся в любом случае менять, если Ваш проект сопровождается графикой. Если он не сопровождается графикой, тогда не придётся менять. Вопрос в сложности продукта. Если продукт сложный — без графа состояний никуда.
Тов. Шалыто, рекомендующий пихать конечные автоматы всюду, демонстрирует классическую ситуацию, когда тема диссертации заняла человека всецело.
This comment wasn’t rated yet0
В рамках автоматного программирования предполагается, что программа пишется только после того, как была спроектирована

Только предполагается? То есть с этим подходом всё-таки возможно писать программу без проектирования? Ненадёжное получается лекарство…
This comment wasn’t rated yet0
В принципе, ничего нового. Мое любимое учебное пособие по теории автоматов в ВУЗе было, емнип, 1974 года. Не помню уже, было ли оно чисто «железячным», или с приложением к программированию тоже, но это очевидный шаг, кмк.
This comment wasn’t rated yet0
вопрос новичка — перемещает ли GC .net блоки данных в памяти? насколько знаю, в java есть несколько областей и объекты могут перемещаться в памяти.
This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr