An offhand remark about why some code was going to get implemented as a sea of events and handlers and wouldn't a state machine be a better way. So what is it anyway?
A few months ago I saw a great little blog post about state machines on the Shopify blog. The message was that state machines are great and developers should use them more – given my recent experiences with state machines at CrowdHired, I could certainly agree with that. But it got me thinking, how many times in my developer career have I actually used a state machine (either separate library or even hand-rolled abstraction)? The answer is zero times – which surprised the hell out of me since state machines really are very useful.. Why Developers Never Use State Machines
So, early on you don't feel like your objects' state machine behaviour is complex enough to warrant a "full-blown" state machine (YAGNI and all that jazz), but later on – when it IS complex enough – you feel like you've invested too much time/effort to replace it with something that has equivalent functionality.. Why Developers Never Use State Machines
I would hazard a guess that there are decent state machine libraries for most languages that you can use (the aforementioned
state_machinefor Ruby is just one example). But even a fluffy bunny has a learning curv. Why Developers Never Use State Machines