<story><title>Why Developers Never Use State Machines</title><url>http://www.skorks.com/2011/09/why-developers-never-use-state-machines/</url></story><parent_chain><item><author>fab13n</author><text>Having used state machines a lot for embedded development, I find that they have one huge drawback: the resulting C code is unreadable, which turns maintenance into a nightmare.&lt;p&gt;SM have a key quality: they are a compact and unambiguous way for specifying a behavior. If your system&apos;s behavior is set in stone, it&apos;s worth specifying it as a SM and implementing it as one. This SM is also great to include in a spec, standard, RFC etc. But if the system evolves, small changes can require dramatic reshaping of the machine.&lt;p&gt;Also, they can lead to very efficient implementations, especially if you don&apos;t have the benefits of a serious OS with a fancy scheduler underneath.</text></item></parent_chain><comment><author>fdkz</author><text>This paper talks about an alternative to SMs:&lt;p&gt;&quot;Protothreads: Simplifying Event-Driven Programming of Memory-Constrained Embedded Systems&quot;
&lt;a href=&quot;http://www.sics.se/~adam/dunkels06protothreads.pdf&quot; rel=&quot;nofollow&quot;&gt;http://www.sics.se/~adam/dunkels06protothreads.pdf&lt;/a&gt;&lt;p&gt;source files (~60 lines without comments):
&lt;a href=&quot;http://www.sics.se/~adam/pt/&quot; rel=&quot;nofollow&quot;&gt;http://www.sics.se/~adam/pt/&lt;/a&gt;&lt;p&gt;abstract:&lt;p&gt;Event-driven programming is a popular model for writing programs for tiny embedded systems and sensor network nodes. While event-driven programming can keep the memory overhead down, it enforces a state machine programming style which makes many programs difficult to write, main- tain, and debug. We present a novel programming abstraction called protothreads that makes it possible to write eventdriven programs in a thread-like style, with a memory overhead of only two bytes per protothread. We show that protothreads significantly reduce the complexity of a number of widely used programs previously written with event-driven state machines. For the examined programs the majority of the state machines could be entirely removed. In the other cases the number of states and transitions was drastically decreased. With protothreads the number of lines of code was reduced by one third. The execution time overhead of protothreads is on the order of a few processor cycles.</text></comment>
<story><title>Why Developers Never Use State Machines</title><url>http://www.skorks.com/2011/09/why-developers-never-use-state-machines/</url></story><parent_chain><item><author>fab13n</author><text>Having used state machines a lot for embedded development, I find that they have one huge drawback: the resulting C code is unreadable, which turns maintenance into a nightmare.&lt;p&gt;SM have a key quality: they are a compact and unambiguous way for specifying a behavior. If your system&apos;s behavior is set in stone, it&apos;s worth specifying it as a SM and implementing it as one. This SM is also great to include in a spec, standard, RFC etc. But if the system evolves, small changes can require dramatic reshaping of the machine.&lt;p&gt;Also, they can lead to very efficient implementations, especially if you don&apos;t have the benefits of a serious OS with a fancy scheduler underneath.</text></item></parent_chain><comment><author>zwieback</author><text>Exactly my experience. Over the years we&apos;ve tried many different ways of coding state machines and it&apos;s very hard to keep them readable. Still we continue to use them, the pros outweigh the cons.&lt;p&gt;There&apos;s a pretty interesting RTOS approach based on state machines (www.state-machine.com, no less) that uses single-stack run-to-completion &quot;tasks&quot;. They also have some kind of wizard approach to generate code but I haven&apos;t had enough time to evaluate it.&lt;p&gt;For anyone who finds state machines in HLLs unreadable, try looking at a state machine implemented in ladder logic on a PLC!</text></comment>