Why developers should be force-fed state machines

This is mostly a description of state, not of state machines.<p>Status, published, or paid fields on your objects have little to do with state machines if the code is not written with assertions about the current state of the application. These fields are just... well plain state, and no machine.<p>One would learn more about state machines from looking at the Ruby gem that's linked to in the article: <a href="https://github.com/pluginaweek/state_machine" rel="nofollow">https://github.com/pluginaweek/state_machine</a>

State machines should be force-fed simply because they are the simplest computational model, and if they are sufficient for a task, to use something more complicated would be illogical. Indeed, in computer science school, they generally <i>are</i> force-fed, followed of course by force-feedings of push-down automata and various Turing Machines. (And if your web app is modeled as a very long tape, that is probably bad.)

Great post. I think it is important that more developers learn the importance of managing state. Almost every application ends up with the kind of bugs where you have two properties set on an object that are mutually exclusive, and you can do nothing but scratch your head and try to reproduce the steps that got you there.<p>Even more important than in Rails-style server-side MVC, though, is using state management in stateful client-side MVC, like Mac, iOS/Android, and web applications. (See <a href="http://gmoeck.github.com/2011/03/10/sproutcore-mvc-vs-rails-mvc.html" rel="nofollow">http://gmoeck.github.com/2011/03/10/sproutcore-mvc-vs-rails-...</a> to understand the difference.)<p>At least with Rails, the flow through your application is pipelined M-&#62;C-&#62;V and the debugging is significantly easier. If you think about an iOS application, for example, your application is starting off in a different state every time, and is constantly being modified by the user. If you ever get into bad state, it can be very hard for the user to recover; especially if that bad state gets persisted to the file system.<p>One problem with state machines is that they grow in complexity very quickly, and the tools that were given to most people in their CS curriculum don't help you manage this fast growth. However, applications that are mission-critical still need the robustness of formalized state management.<p>David Harel, while working on software for fighter jets, came up with Harel statecharts, which describe a formalism for parent and child states. These are also very popular in embedded systems, such as pacemakers, where users could die if the system fails:<p><a href="http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Statecharts.pdf" rel="nofollow">http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Stat...</a><p>We've been preaching statecharts pretty hard in the SproutCore community, although largely internally at Apple, and included a built-in statechart library in our 1.5 release. Mike Cohen, the maintainer of the SC library, has a ton of great resources on his blog:<p><a href="https://frozencanuck.wordpress.com/category/statecharts/" rel="nofollow">https://frozencanuck.wordpress.com/category/statecharts/</a><p>I think especially in the arena of web applications, we need to start spreading the word about the benefits of statecharts, not least of which is the easy ability to regenerate state from URLs. It requires discipline and effort upfront, but so does unit testing, and I think that's a battle that the development community has largely won.

Last time I ran into a business process coded as a state machine in the wild it was this horrible mess of code that no one could understand. After staring at it for a while, going through it line by line... finally the lightbulb went off and I was "oh! It's a state machine! I know what they're trying to do now!"<p>Kind of a Neo "I know Kung Fu" moment.<p>Unfortunately, no one else on the team knew/remembered anything about state machines, so my epiphany didn't help them out any, even if they had had the same kind of classical Comp Sci education as me.<p>Naturally, the first thing I did with this power was to leverage it into World Domin... no wait, that was something else. :D What I did with this knowledge was to hassle the people until they gave me a diagram of what the state transitions (or whatever they called them in Business Analyst land) were supposed to be, and then I went back and compared them, and they were not the same :(

Erlang comes with gen_fsm behavior because often when writting network protocols and servers, a state machine is a useful abstraction.<p>Relevant:<p>"Rage Against The Finite-State Machine" from "Learn you some Erlang For Great Good"<p><a href="http://learnyousomeerlang.com/finite-state-machines" rel="nofollow">http://learnyousomeerlang.com/finite-state-machines</a>

So, more often than not, you'll catch your state machines attaching behavior directly to your objects. Which sometimes bugs you, because you want your states to be less about "nouns" and more about "verbs".<p>And eventually you notice that, in most cases, you crave coordination across those "nouns" (e.g.: "a transition in model A provokes a transition in model B"). The real workflow now lies "at the intersection of two models". You start to wish for the equivalent of "process management" in addition to state management.<p>So this, coupled with general unhappiness for the sort of anti-modular/anti-abstraction problem you see in state machines, might incite you to look at "workflow engines" like Ruote.<p><a href="http://ruote.rubyforge.org/" rel="nofollow">http://ruote.rubyforge.org/</a><p>TL;DR I am drinking the 'ruote' kool-aid right now. Augment your state machines with a great coordinator in the sky, a few levels higher in the architecture stack.<p>(BTW: I'm paraphrasing this argument from John Mettraux's "state machine != workflow engine" post, and Kenneth Kalmer's Ruote presentation from this year. Really changed my thoughts on the matter recently.)

Using the state_machine gem in one of our Rails apps, which tracks a workflow where items can be received, entered, reviewed, rejected, etc, helped me think through the business process and map that to our code.<p>We also logged all the changes in state. In hindsight, I should have added a "previous log entry" field to each log item, to make it easier to trace the history of any given item. Like "find all the rejections, hop back one through the log history and show me who created that item." If the rejection references the creation's id, that's easy; otherwise it's a query using widget ids and the date and sorting to get the most recent entry before the rejection.

It is interesting how few languages make state machines easily read when the appear in code ("what's with all the ifs?").

this is why i like ragel (<a href="http://www.complang.org/ragel" rel="nofollow">http://www.complang.org/ragel</a>) a lot. seems that zed-shaw also has used it in couple of his projects e.g. mongrel most notably. would be particularly cool if ragel can be combined automagically for some protocol parsing tasks...

Learning HDL (e.g., Verilog or VHDL) is a great way to force-feed yourself state machines.

State machines are anti-modular.<p>State machines are anti-abstraction.<p>State machine code is hard to read.

I skimmed the whole thing before realizing I had parsed the headline wrong.

For any .Net people here, this is a great piece of kit:<p><a href="http://code.google.com/p/stateless/" rel="nofollow">http://code.google.com/p/stateless/</a>

This is not an interesting thought for someone who has a degree.