Hacker News Reader

Comment by patrickg | Hacker News Reader

I do have a degree in computer science so I know about state machines. Yet I don't use them at all in my code. Am I missing a great opportunity? I know it is close to impossible to answer that question without knowing the problem space, but perhaps there is a nice article about solving (common) problems with state machines?

View on HN

It's possible you use state machines and don't know it :) Have you ever used loop with if inside, that dispatches based on value of some variable? That's state machine implementation in structured language.

I've encountered such code many times in our codebase.

Or maybe you used some business process engine (like jbpm) - that's also state machine.

I've even made jbpm-like engine in javascript for my html5 game - I use it to write quests in my game, and I plan to refactor dialog trees to also use it.

It's graph with nodes and transitions, nodes specify actions game should do, transitions specify conditions player has to do to move to next node.

Here's code if anybody's interested: https://github.com/ajuc/pefjs

And here's graphical editor for graphs: https://github.com/ajuc/jsDotForPefjs

Anything that implements a series of transactions that change internal variables of some structure is an ideal candidate for a state machine.

OLTP software, network stacks, computer games, object based simulations and so on are all good examples of things that you could probably implement a lot easier using state machines than you could ever implement them using some other coding technique (likely you'd be re-implementing state machines anyway, just not by name and in a warped form).

Statemachines get rid of the endless series of flags and ugly error handling that would otherwise govern a re-start of a chunk of code at a later date without assigning a thread to each datum that passes through the system.

They're generally useful when you need to process input and keep track of what to do "next".

Here's an example where the author manages comet connections using gen_fsm in Erlang:

http://www.letsyouandhimfight.com/2010/01/31/comet-in-erlang...

The FSM starts in state "waiting" (waiting for a connection/request). When a request arrives, the state is transitioned to "have_request". When/if a packet arrives when there's a request connected (packet -> have_request), the data is sent to the client (that then disconnects; the nature of this comet implementation) and the next state is set to "waiting". When a packet arrives when the current state is "waiting", it's added to a buffer and the next state is set to "have_packet". When a request is made and the state is "have_packet" - as opposed to when it was in "waiting" - the packet is immediately sent to the client, and the next state is set to "waiting". There are many other states and "events" in the code, but I think this illustrates how easy FSMs make it to reason about these kind of implementations (protocols).

There's a lot of code that doesn't benefit from state machines at all.

But when code does profit from a state machine, it's often easy to recognize from the many 'if' statements that check several flags (like ' if (seen_input && !eof && ..)')

I once wrote a toy video-player program, and I was able to implement robust, interactive playback controls fairly cleanly by structuring it as a state machine.

Reply on news.ycombinator.com