Why Developers Never Use State Machines

Use them all the time, have for all my career.

They organize complex code, dissect complex set-flag-here-and-test-there spaghetti into a matrix of states and events that can be exhaustively examined and debugged.

Yes you have to organize your code to feed the machine (Vol is hungry! We must feed Vol!) But you have to organize your code somehow, and feeding a state machine can actually be easier to understand that flag-setting. In fact, it makes it absolutely clear what an event is associated with - the machine it feeds.

Upon reading this, I realized I had never really looked into state machines much. In my searching, I found a Coffeescript state machine that has a nice chess-based example:

https://github.com/stephenb/coffee-machine

It's used a lot in Erlang, FWIW. It's used so much that OTP has a built-in finite state machine behavior[0].

Of course having nicely isolated processes probably helps noticing that you have an ad-hoc state machine on your hands.

[0] http://www.erlang.org/doc/design_principles/fsm.html

If you are a C developer, try Ragel [http://www.complang.org/ragel]. I use it lot, also can be easily pared with the Lemon parser generator.

FSMs are very common on the embedded systems I work on. In fact, I often find that my coworkers use them too much. For instance, sometimes a DSP filter would be a much cleaner and maintainable solution. That said, if you work on embedded systems and you've never used a FSM, you're probably doing it wrong ;)