Comments 18
Подумайте почему в области программирования логических контроллеров, где все алгоритмы отлично описываются автоматами практически ушли от графической нотации автоматов.

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

Поэтому программу легче писать просто вылавливая и обрабатывая нужные сочетания сигналов. Нет никакой необходимости эти сочетаний кодировать в состояния. И некое проектирование тут ни к чему и даже невозможно.
Скажем на этапе разработки программы для ПЛК можно даже не знать заранее всё поведение объекта. Программа развивается в стиле патчей. Узнали о новом поведении — добавили обработку характерных сочетаний сигналов.
Никаких состояний, никаких диаграмм переходов! Это некая реализация реактивного программирования. Особенно удобно в сочетании с многозадачностью и RTOS.
Это признанная практика.

А автоматы и плохо масштабируются, и совершенно не гибкие и труднее отлаживаются, требуют «проектирования»
Автоматы хороши на низком уровне. Например протокол PPP, реализуется на таблице переходов. Это приемлемо, хорошо формализовано. Но это очень простой протокол. А вот изобразить автоматами WEB сервер уже не выйдет.
просто вылавливая и обрабатывая нужные сочетания сигналов [...] Узнали о новом поведении — добавили обработку характерных сочетаний сигналов.
Никаких состояний, никаких диаграмм переходов!

это верно когда новое поведение сосуществует параллельно с ранее запрограммированным. но когда новое сочетание сигналов вклинивается в ранее созданный алгоритм, это уже не соответствует действительности.
А автоматы и плохо масштабируются, и совершенно не гибкие и труднее отлаживаются,
хорошо что вы подняли эту тему. Как раз в случае когда автоматы «проектируются», не возникает проблем ни с отладкой ни с масштабируемостью ни с гибкостью.
Когда я был молодым и разработал «Дисплей» не так как это показано в примере, в какой то момент я убедился, что добавление новых свистелок «наступает на пятки» предыдущим, но когда я изобразил всё как показано в предыдущем примере, для всего нашлось место. Более того, я покажу как этот пример можно модифицировать.
С отладкой тоже не возникает проблем. У меня примерно 40% времени занимает проектирование, 20-30% написание кода, 10%! отладка, и остальное время я просто добавляю в программу кучу всяких фич, от которых тащатся заказчики. То есть, я не хвастаюсь сейчас, я обычный программист, я не отличаюсь особым вниманием и где то рассеян даже более чем остальные, но понимаете, отладка когда я разработал программу автоматно сводится в основном к тому чтобы убедиться что всё ок, и я хочу чтобы в будущем молодые программисты не убивались со слезами на глазах о необъяснимое поведение программы, и не лысели раньше времени.
Скорее всего у вас некий частный случай.
Наверно станут яснее ваши мысли когда вам придется полнее раскрыть в какой области работаете.
А то что вы пытаетесь говорить за все программирование не рассказав о своей личной квалификации только увеличивает недоверие к вашему мнению, уж извините.

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

А если вы удачно придумали один автомат и его успешно копируете из проекта в проект, то это не интересно, это не технология.

Я разработчик лабораторных измерительных приборов, msp arm микроконтроллеры разные. В институте я изучил автоматы для железа. Может это и осталось бы просто предметом, но был серьёзный курсач (система сбора данный втыкаемая в ISA), и я оценил всю силу микропрограммных автоматов. Я сделал это, хотя сначала даже не знал как подступиться. Обычное программирование знаю с детства но когда оно стало моей работой, в силу обстоятельств у меня после института было достаточно времени чтобы начать писать проги как автоматы, благо поставленная задача — стенд автоматизированного тестирования плат, прямо таки располагала к автомату. Я «вошёл в форму» и писал все модули управления периферией контроллера как автоматы. Сначала просто для себя, молодой исследователь, но потом это сложилось в систему, которую я довёл до некоторого уровня, когда можно поделиться с коллегами.
Лет 10 назад я обратился к интернету посмотреть — делает ли кто нибудь как я, но понял что автоматное программирование воспринимается несколько однобоко, и от этого оно кажется куцым. Я вас понимаю, если смотреть на программные автоматы так, как это предписывается распространённой практикой, в них мало преимуществ, поэтому я начал этот цикл, и сейчас как начинающий писатель я пытаюсь понять что писать чтобы был понятен именно процесс автомато-ориентированной разработки. Проект «Дисплей» неплохой вариант, это показательный пример. В следующей статье я обрисовываю его же только несколько с другого ракурса. Если вы после этого задатите конкретные вопросы, я смогу написать ещё более понятно. Я намерен сделать пособие, потому что автоматное программирование это подход к решению задачи а не только способ оформления, реализации программы.
Вероятно отладка у вас будет занимать меньше времени когда вы будете больше времени уделять планированию, проектированию модулей, именно в графическом виде. Просто всегда есть вопрос — а что собственно рисовать — это и хочу показать, просто я нащупываю почву чтобы читателю было понятно — я не преподаватель и это мой первый опыт обучения людей через лекции ) Спасибо что читаете

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

о есть, вы не встречали программ на автоматах, разработанных другими людьми.

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

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

Пишите, конечно.
Эти поиски серебряной пули всегда интересны.

Однако если ваш подход ничем внешне (ни нотацией, ни организацией) не отличается от обычного программирования, то в чем его суть? Я также применяю switch-case. Также некоторые переменные у меня имеют тип перечисления. Я также некоторое время сижу в ступоре и думаю сколько состояний должна иметь переменная, типа проектирую. У вас же проектирование тоже никак не формализовано (с чего начинаться, чем заканчиваться)
Но я ничего уже не помню по теории автоматов, никогда сильно в ней не разбирался и даже желания нет разбираться.
Что это с о мной? Как я умудряюсь программировать в терминах состояний? Или я жутко неэффективно программирую?
Вот, допустим, моя реализация монитора VT100. Не предлагаю анализировать этот текст, а только обратить внимание сколько там switch-case. И это все было написано без единой мысли о некоем автоматном программировании.

множественная альтернатива != автоматное программирование. Благодаря популяризаторству Шалыто они немного звучат как будто из одной оперы. Хотя стоит отдать ему должное — он популяризаторствует уже лет 30 судя по его книгам, этакий Донкихот и первопроходец 2 в 1. Может он и увидит эру автоматного программирования. Надеюсь у него хватит непредвзятости чтобы принять автоматное программирование таким какое оно будет, и не замыкаться на switch-операторе
Главным атрибутом автоматно реализованной программы является:
текущее состояние программы описывается одной единственной переменной, которая называется Внутреннее состояние автомата...
Позвольте не согласится. У меня в одной программе было две переменные, т.е. матрица состояний. И это был очень такой показательный автомат. Можно конечно свести это к одной переменной вида i*N+j — но это будет сова на глобусе.
Характерная черта неавтоматного программирования, это то, что состояние программы в каждый момент времени описывается не только программным счётчиком, но и некоторым количеством внутренних флагов.
Опять. Просто умножаем мощность переменной на мощность этих флагов. И пишем switch(flag1+flag2*2+N*4). ИМНО автомат это не то когда «состояние зависит от одной переменной», а когда «программу удобно написать в виде автомата».

К тому же можно на одном контроллере реализовать более одного автомата (например один автомат в прерываниях UART...), и бессмысленно это сливать все в один и они будут двумя сферическими автоматами, зависящих минимум от двух переменных. (У Вас тоже пример с двумя автоматами, но немного не так)

В общем каждый уважающий себя embedded программист изобретает свой автомат.
У меня в одной программе было две переменные, т.е. матрица состояний. И это был очень такой показательный автомат. Можно конечно свести это к одной переменной вида i*N+j — но это будет сова на глобусе.
трудно обсуждать это даже не «на пальцах». Если не сложно, напишите об этом попримеристей. Это может стать иллюстрацией для дальнейшего хода повествования. Автоматное программирование — общее дело, мы сами создаём будущее.
Просто умножаем мощность переменной на мощность этих флагов.
не остонавливайтесь на этой фразе, читайте весь абзац, там об этом и написано )

К тому же можно на одном контроллере реализовать более одного автомата (например один автомат в прерываниях UART...), и бессмысленно это сливать все в один и они будут двумя сферическими автоматами, зависящих минимум от двух переменных.
речь не идёт о том что — один микроконтроллер — один автомат. Речь о том что отдельно взятый, логично законченный кусок алгоритма, программный модуль — это автомат.
Поскольку статья научно популярная, то что вы пишите это важно, такие моменты я постараюсь проиллюстрировать.

В общем каждый уважающий себя embedded программист изобретает свой автомат
примерно так и есть. Сделаем мир вокруг нас немного лучше
где то на хабре видел статью, если не ошибаюсь, о минимальном времени посещения всех станций Московского метрополитена. Так вот автор построил алгоритм графами визуально, вбил в какую то программу и с помощью КА решил задачку, очень красиво доходчиво пояснял.
Так вот его метод показался более интересным. Он сначала рисовал диаграмму со всеми входными выходными состояниями, а потом генерил не читабельный но шустрый и стабильный код. Так вот, чтобы поддерживать программы на КА мог кто то другой, возможно стоит посмотреть в строну развития КА в этом направлении:
Мы не читаем и анализируем код, в случае его доработки мы читаем и анализируем диаграммы, вносим в них изменения, а софт нам уже генерит уродливый но шустрый код машины состояний.
Какие проблемы может вызвать данный подход?
Проблема тут та же самая что и с любыми графическими языками программирования: многословность любых нетривиальных алгоритмов.
Почему обязательно графическим? КА может быть описан каким-то кодом: регулярками, БНФ, и т.п.
Так вот его метод показался более интересным. Он сначала рисовал диаграмму со всеми входными выходными состояниями, а потом генерил не читабельный но шустрый и стабильный код. Так вот, чтобы поддерживать программы на КА мог кто то другой, возможно стоит посмотреть в строну развития КА в этом направлении

К регуляркам же, БНФ или DSL (который Domain-specific language) претензий у меня нет. Так же как и к сопрограммам.

Извините за задержку с ответом, проглядел коммент.
Но в описываемой вами задаче не было задано никакого алгоритма графами визуально. Это была задача обхода графа: граф отражал не алгоритм решения, а условие задачи. Алгоритмы же там, как пишет сам автор — генетические.
а потом генерил не читабельный но шустрый и стабильный код
очень интересно, если бы вы рассказали подробнее об этом коде. Насколько понял это я, там речи не шло о коде вообще, а рассматривались перестановки вектора из 200 станций метро, с целью минимизации длины. Были описаны условия — как осуществлять перестановки — это и есть алгоритм.
Мы не читаем и анализируем код, в случае его доработки мы читаем и анализируем диаграммы, вносим в них изменения, а софт нам уже генерит уродливый но шустрый код машины состояний.

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

Это немного наивная вера в то, что некий софт может сгенерить код, недоступный для создания человеком. Однако это не верно, в одной из следующих статей я как раз рассуждаю об эффективности. В этом отношении «уродство» кода как раз не признак эффективности. В основе эффективности — «красота» замысла, и эта же красота первопричина того, что эффективный код, как правило, не уродлив, а наоборот.
Only those users with full accounts are able to leave comments. Log in, please.