I programed a State Machine app once in my career and it was much much more difficult to program than ordinary C# code development. It took a very long time to develop the app for MS sharepoint that required it many years ago. I remember calling MS support and even they could no really help me. I spoke to them for hours eventually and I got nothing done. I had to figure it out myself. I think it requires a different way of thinking than what developers are used to. It was not worth the time and effort.
Why developers never use state machines (2011)
11–20 of 121 posts
Re: Why developers never use state machines (2011)
#12As someone who started in video game development...
...beyond trivial stuff like pong, the natural pattern is just a big collection of state machines (as entities) interacting with each other.
Re: Why developers never use state machines (2011)
#13I'm an EEE, and one of the strange things I've noticed is that, for whatever reason, people from a CompSci background is really, really have trouble building and understanding even simple state machines. I suspect this unintuitiveness is the main reason why we don't see more state machines, as even in the case where they're an optimal solution many SWEs will shy away from them. Locally-rendered UIs are probably one o…
They do not scale well. It is why Elm-style explicit message passing UIs are not popular. State machines work for state localised to a widget, but the moment you scale up to something moderately complex (spreadsheets, datagrids, forms etc.), your diagrams balloons in size. For non safety-critical applications, it is better to have implicit state and potential bugs than to have your engineering team waste time proving the correctness of a button when they could be building features instead.
SWEs (at least those with formal CS training) understand state-machines perfectly well. It is the kernel of regular expressions and parsing. Mapping it to a product UI just doesn't make sense all the time.
Re: Why developers never use state machines (2011)
#14As a regular user of the state_machine Ruby gem, I wouldn't recommend it. If you don't believe me, just check out the "Class definition" section of the usage examples: https://github.com/state-machines/state_machines#usage
The problems are obvious. It's built on magic and indirection. This leads to difficult to debug state machine problems. For anything beyond simple state machines you quickly lose any idea of what your object is doing.
Re: Why developers never use state machines (2011)
#15State machines are commonly used in game development.
Re: Why developers never use state machines (2011)
#16The answer is LabVIEW. State machines in a graphical language are a joy and very easy to work with. It’s clear what state you’re looking. At and how to trace the execution. Most text language based state machines are a mess and difficult to reason about. FWIW I maintain a state machine library for Ruby called wicked that (IMHO) isn’t too bad, but can still get gnarly if you’re not careful.
I think you are the first person I've seen call LabVIEW a joy ;-)
Re: Why developers never use state machines (2011)
#17I'm an EEE, and one of the strange things I've noticed is that, for whatever reason, people from a CompSci background is really, really have trouble building and understanding even simple state machines. I suspect this unintuitiveness is the main reason why we don't see more state machines, as even in the case where they're an optimal solution many SWEs will shy away from them. Locally-rendered UIs are probably one o…
I was trained as an EE and occasionally use a state machine in my code. Every other time I've encountered a state machine it was also written by someone trained as an electrical engineer or similar.
Re: Why developers never use state machines (2011)
#18I'm an EEE, and one of the strange things I've noticed is that, for whatever reason, people from a CompSci background is really, really have trouble building and understanding even simple state machines. I suspect this unintuitiveness is the main reason why we don't see more state machines, as even in the case where they're an optimal solution many SWEs will shy away from them. Locally-rendered UIs are probably one o…
In software, it’s rare that two states can be transitioned between synchronously. Or at least, modeling a problem in terms of states that have synchronous transitions is hard. Waiting for user input, making a network request, disk IO, etc. are all asynchronous. This makes it annoying to design a state machine.
Just as an example, imagine you have two states you want to model, A and B. Let’s say the transition between A and B requires 3 async operations. You then need 8 total states: A, A_before_step_1, A_before_step_2, A_before_step3, B, B_before_step_1, B_before_step_2, and B_before_step_3. It just becomes totally unmanageable.
Re: Why developers never use state machines (2011)
#19Computers ARE state machines and the primary purpose of a programming language is to help humans manage all this state.
Re: Why developers never use state machines (2011)
#20I feel state machines might be better represented as validations happening behind the scenes, e.g. if my coffee machine's state would go from COFFEE_READY to CUP_PLACED then allow it, if it would go straight to COFFEE_POURING with no cup then throw an error. I'm not convinced you need explicit events, and think most of the value is in preventing nonsensical transitions between states.