<story><title>Why Developers Never Use State Machines (2011)</title><url>https://www.skorks.com/2011/09/why-developers-never-use-state-machines/</url></story><parent_chain><item><author>s4vi0r</author><text>Traditional programming languages and imperative thinking don&amp;#x27;t lend themselves to writing state machines, so its not really that surprising that they&amp;#x27;re under utilized.&lt;p&gt;Its kind of frustrating constantly reading posts where people shit on functional programm(ers|ing) for being too ivory tower-y or whatever, when its kind of hard not to be when a lot of the older FP guys have spent the last like 20-30 years going &amp;quot;yo this is dope you guys should really be doing this&amp;quot; and getting largely ignored. State machines are super commonly used in languages where you can (easily) construct ADTs and pattern match on them.</text></item></parent_chain><comment><author>simonh</author><text>&amp;gt;the older FP guys have spent the last like 20-30 years going &amp;quot;yo this is dope you guys should really be doing this&amp;quot; and getting largely ignored&lt;p&gt;I&amp;#x27;ve not been ignoring them. I tried at least three different Haskell tutorials and articles explaining how cool it is. The problem was the author would show some code sand say &amp;#x27;see how easy it is to do this, and this, and this!&amp;#x27;, but I&amp;#x27;d look at the code and have no idea whatever what it was doing or how it was doing it, and the guide&amp;#x2F;tutorial wouldn&amp;#x27;t tell me. After a few tries, I just gave up.&lt;p&gt;Maybe there&amp;#x27;s a canonical newbie&amp;#x27;s tutorial that takes you through the shift from imperative&amp;#x2F;procedural thinking?</text></comment>
<story><title>Why Developers Never Use State Machines (2011)</title><url>https://www.skorks.com/2011/09/why-developers-never-use-state-machines/</url></story><parent_chain><item><author>s4vi0r</author><text>Traditional programming languages and imperative thinking don&amp;#x27;t lend themselves to writing state machines, so its not really that surprising that they&amp;#x27;re under utilized.&lt;p&gt;Its kind of frustrating constantly reading posts where people shit on functional programm(ers|ing) for being too ivory tower-y or whatever, when its kind of hard not to be when a lot of the older FP guys have spent the last like 20-30 years going &amp;quot;yo this is dope you guys should really be doing this&amp;quot; and getting largely ignored. State machines are super commonly used in languages where you can (easily) construct ADTs and pattern match on them.</text></item></parent_chain><comment><author>gopalv</author><text>&amp;gt; Traditional programming languages and imperative thinking don&amp;#x27;t lend themselves to writing state machines&lt;p&gt;That&amp;#x27;s probably not the problem - imperative development can start off from a level of complexity where state machines don&amp;#x27;t look relevant.&lt;p&gt;Six weeks down the line, the whole codebase has overtaken the complexity of a state machine, though each of the development bugs were simple fixes to the original branching code.&lt;p&gt;The standard web-app wizard is where I&amp;#x27;ve run into this again and again.&lt;p&gt;Every web-app is stateful enough to maintain DB state sync&amp;#x27;d &amp;amp; ticking over from  a user-click, which makes it really easy to work out whether all clicks go somewhere useful.&lt;p&gt;However this makes sense only when you have around 7+ states and transitions between them (particularly the &amp;quot;go back&amp;quot; one).&lt;p&gt;Until then, the regular if&amp;#x2F;else branch scenarios work out just fine ... but then when you&amp;#x27;re near the 20-30 state range, it all falls apart.</text></comment>