Live data from Hacker News

Why Developers Never Use State Machines (2011)

skorks.com

161–164 of 164 posts

Re: Why Developers Never Use State Machines (2011)

#161
post #117

One thing formal state machines make difficult is component reuse. Let's say you have a music playback control component you wish to reuse across a feature rich player, as well as a mini playback controller. You COULD just use the full state machine to power the mini player, but most of the transitions would be unused. It would be unclear to the next maintainer which aspects were needed for each use case, thus making…

This was a nice thing in the example from Raganwald's blog post. The `transitionsTo` decorator: function transitionsTo (stateName, fn) { return function (...args) { const returnValue = fn.apply(this, args); this[STATE] = this[STATES][stateName]; return returnValue; }; } By separating the state transitions from the state actions in this way it allows the functional components to be reused much more easily. You can con…

This is a nice approach, thank you for pointing it out.

I'd argue that you are building a separate state machine for the two players, but there is some reuse possible in this approach.

Re: Why Developers Never Use State Machines (2011)

#162
post #117

One thing formal state machines make difficult is component reuse. Let's say you have a music playback control component you wish to reuse across a feature rich player, as well as a mini playback controller. You COULD just use the full state machine to power the mini player, but most of the transitions would be unused. It would be unclear to the next maintainer which aspects were needed for each use case, thus making…

Ah... your "independent playback progress/state class" is another state machine, just better with an architecture that suits your use case. "Full state machine" is a misnomer and common misunderstanding of the power of state machines. Any state machine bordering on complexity that is hard to manage can be broken into multiple smaller, easier to grasp and manage state machines. And state machines transparently integra…

I wouldn't consider this class a state machine in the sense described in the paper.

Any class managing state exclusively is an implicit state machine, no?

Re: Why Developers Never Use State Machines (2011)

#163
may be some of developers don't know this technique and more evident that they never tried to work with end state machines. I am using state machine long time and made my own script player for SM, unlike to others SM i am using it in different implementation from web till equipment automation. https://github.com/series6147/ProcessPlayer-state-machine

Re: Why Developers Never Use State Machines (2011)

#164
post #27

One of my go-to interview questions is "Can you tell me about a time when you've used an explicitly-modeled state machine in your programming?" Our work, heavy in embedded devices, network protocols, and parsing, is so full of state machines that I wouldn't want to hire someone who wasn't comfortable using them.

For equipment automation i am using end-state player which accelerate our development at least in 3 times. Why? There are three levels of hierarchy: conception level, detail, gui. All of these levels are independant to earch others, for example, arhitector can invented new conception with some fake elements which will be substituted in some future stages. Software developers who are making new elements (with parsers, new libraries and so on), regarding to conception above, are not intersected with conception and gui levels. In its turn gui developers use only state schema with all defined properties or data which are belong to every state.
Post reply on HN