6 ms·

> riddled with state machines Why is this bad? Normally, state machines are easy to reason about.

by throwaway2037 2y ago

lmm 2y ago
I've never understood this claim. I find state machines very hard to follow because there's no easy way to tell what paths lead to a given state; they're like using goto instead of functions (indeed they're often implemented that way).
AnimalMuppet 2y ago
They can be. Or they can be... less easy. Imagine you have an informally-specified, undocumented, at-least-somewhat-incomplete state machine. Imagine that it interacts with several other similar state machines. Still easy to reason about? Now add multithreading. Still easy? Now add locking. Still easy? Cleanly-done state machines can be the cleanest way to describe a problem, and the simplest way to implement it. But badly-done state machines can be a total mess. Alas, I think that the last time I waded in such waters, what I left behind was pretty much on the "mess" side of the scale. It worked, it worked mostly solidly, and it did so for more than a decade. But it was still rather messy.
- pjc50 2y ago
  > Now add multithreading. Still easy? > Now add locking. Still easy? Don't do that then. Or rather, either manipulate the state machine from only a single thread at a time; or explicitly turn the multithreading into more states. If you need to wait for something instead of having "do X" you transition into state "doing X". C#-style async does this in a state machine behind the scenes.
- rramadass 2y ago
  But that is just true of any problem-solving/programming technique. In general, state/event machine transition table and decision table techniques of structuring code are easier to comprehend than adhoc and even worse, poorly understood pattern-based techniques are.
- lelanthran 2y ago
  > Imagine you have an informally-specified, undocumented, at-least-somewhat-incomplete state machine. Imagine that it interacts with several other similar state machines. Still easy to reason about? You think that developers that wrote an informally-specified, undocumented, at-least-somewhat-incomplete state-machine would have written that logic as a non-state-machine in a formally-specified, documented and at-least-somewhat-complete codebase? State-machines are exceptionally easy to reason about because you can at least reverse-engineer a state-diagram from the state-machine code. Almost-a-state-machine-but-not-quite are exceptionally difficult to reason about because you can not easily reverse-engineer the state-diagram from the state-machine code.
  - gpderetta 2y ago
    In fact state machines are great for documentation even if the code is not explicitly written as a state machine!
    - _huayra_ 2y ago
      Yes, and it's much better than having a dozen or more `bool` values that indicate some event occurred and put it into some "mode" (e.g. "unhealthy", "input exhausted", etc) and you have to infer what the "hidden state machine is" based on all of those bool values. Want to add another "bool state"? Hello exponential growth...
risenshinetech 2y ago
Please describe "normally". State machines can turn into nightmares, just like any design pattern used poorly.
majormajor 2y ago
The set of developers who say "I want to implement this logic as a state machine" is MUCH larger than the set of developers who say "I should make sure I fully understand every possible state and edge case ahead of time before making a state machine!"
- harrall 2y ago
  The times I’ve bothered to write explicit state machines have created the most solid, confident and bug-free pieces of software I’ve ever built. I would send someone to the moon with them.
- throwaway2037 2y ago
  Couldn't this be said about any alternative solution? I fail to see how this is specific to state machines. What do you suggest instead of a state machine?
  - majormajor 2y ago
    The "riddled with state machines" from the post I was replying to, while sounding negative, is at least better than the "single state machine" which is probably combinatorially huge and would be impossible to maintain. My rough rule of thumb based on experience is that if the state machine being a state machine is visible outside of it's internal implementation (compared to just an interface with operational methods that don't hint at how things are managed behind the scenes) it's probably too leaky and/or incomplete. I would trust code with extensive state-transition testing (regardless of internal implementation) - I wouldn't trust code that claimed to implement a state machine and didn't have that testing, or extensive documentation of edge cases and what was left out of the state machine. As a simple example of something that's often left out in a way that fucks up state machines: the passing of time.
  - bvrmn 2y ago
    Like properly model a domain in domain terms?
    - 2y ago
nurettin 2y ago
State machines don't have syntax for "transition here when event is encountered no matter what state you are in" so the whole diagram becomes a spaghetti mess if you have a lot of those escape hatches.
- a_t48 2y ago
  I believe HSMs can model this, but don't quote me. :)
  - nurettin 2y ago
    Yes, of course in theory nested state machines should be able to model this. I feel like adding more complexity and bending the rules is a bit of a concession.
    - jeffreygoesto 2y ago
      Back in the days we implemented HSM helper classes in about 500 LoC and generated them from Enterprise Architect. No need to write a GUI yourself, but better to have a visual for documentation and review. Worked very well until we replaced EA with docs-as-code, now I miss that there is no nice simulator and Modeler for that workflow.
- quietbritishjim 2y ago
  State machines don't have a native syntax in C++ at all, so you can structure them however you want. It's easy to structure a state machine, if needed, so that all (or some) states can handle the same event in the same way.
  - garethrowlands 2y ago
    Switch + goto is very close to being a native syntax for state machines. It's also very efficient.
  - dgfitz 2y ago
    I always thought this framework was neat: https://doc.qt.io/qt-5/statemachine-api.html https://doc.qt.io/qt-5/statemachine-api.html Downside of course is now you have a dependency on qt.

> riddled with state machines Why is this bad? Normally, state machines are easy to reason about.

lmm 2y ago

I've never understood this claim. I find state machines very hard to follow because there's no easy way to tell what paths lead to a given state; they're like using goto instead of functions (indeed they're often implemented that way).

AnimalMuppet 2y ago

They can be. Or they can be... less easy. Imagine you have an informally-specified, undocumented, at-least-somewhat-incomplete state machine. Imagine that it interacts with several other similar state machines. Still easy to reason about? Now add multithreading. Still easy? Now add locking. Still easy? Cleanly-done state machines can be the cleanest way to describe a problem, and the simplest way to implement it. But badly-done state machines can be a total mess. Alas, I think that the last time I waded in such waters, what I left behind was pretty much on the "mess" side of the scale. It worked, it worked mostly solidly, and it did so for more than a decade. But it was still rather messy.

pjc50 2y ago
> Now add multithreading. Still easy? > Now add locking. Still easy? Don't do that then. Or rather, either manipulate the state machine from only a single thread at a time; or explicitly turn the multithreading into more states. If you need to wait for something instead of having "do X" you transition into state "doing X". C#-style async does this in a state machine behind the scenes.
rramadass 2y ago
But that is just true of any problem-solving/programming technique. In general, state/event machine transition table and decision table techniques of structuring code are easier to comprehend than adhoc and even worse, poorly understood pattern-based techniques are.
lelanthran 2y ago
> Imagine you have an informally-specified, undocumented, at-least-somewhat-incomplete state machine. Imagine that it interacts with several other similar state machines. Still easy to reason about? You think that developers that wrote an informally-specified, undocumented, at-least-somewhat-incomplete state-machine would have written that logic as a non-state-machine in a formally-specified, documented and at-least-somewhat-complete codebase? State-machines are exceptionally easy to reason about because you can at least reverse-engineer a state-diagram from the state-machine code. Almost-a-state-machine-but-not-quite are exceptionally difficult to reason about because you can not easily reverse-engineer the state-diagram from the state-machine code.
- gpderetta 2y ago
  In fact state machines are great for documentation even if the code is not explicitly written as a state machine!
  - _huayra_ 2y ago
    Yes, and it's much better than having a dozen or more `bool` values that indicate some event occurred and put it into some "mode" (e.g. "unhealthy", "input exhausted", etc) and you have to infer what the "hidden state machine is" based on all of those bool values. Want to add another "bool state"? Hello exponential growth...

risenshinetech 2y ago

Please describe "normally". State machines can turn into nightmares, just like any design pattern used poorly.

majormajor 2y ago

The set of developers who say "I want to implement this logic as a state machine" is MUCH larger than the set of developers who say "I should make sure I fully understand every possible state and edge case ahead of time before making a state machine!"

harrall 2y ago
The times I’ve bothered to write explicit state machines have created the most solid, confident and bug-free pieces of software I’ve ever built. I would send someone to the moon with them.
throwaway2037 2y ago
Couldn't this be said about any alternative solution? I fail to see how this is specific to state machines. What do you suggest instead of a state machine?
- majormajor 2y ago
  The "riddled with state machines" from the post I was replying to, while sounding negative, is at least better than the "single state machine" which is probably combinatorially huge and would be impossible to maintain. My rough rule of thumb based on experience is that if the state machine being a state machine is visible outside of it's internal implementation (compared to just an interface with operational methods that don't hint at how things are managed behind the scenes) it's probably too leaky and/or incomplete. I would trust code with extensive state-transition testing (regardless of internal implementation) - I wouldn't trust code that claimed to implement a state machine and didn't have that testing, or extensive documentation of edge cases and what was left out of the state machine. As a simple example of something that's often left out in a way that fucks up state machines: the passing of time.
- bvrmn 2y ago
  Like properly model a domain in domain terms?
  - 2y ago

nurettin 2y ago

State machines don't have syntax for "transition here when event is encountered no matter what state you are in" so the whole diagram becomes a spaghetti mess if you have a lot of those escape hatches.

a_t48 2y ago
I believe HSMs can model this, but don't quote me. :)
- nurettin 2y ago
  Yes, of course in theory nested state machines should be able to model this. I feel like adding more complexity and bending the rules is a bit of a concession.
  - jeffreygoesto 2y ago
    Back in the days we implemented HSM helper classes in about 500 LoC and generated them from Enterprise Architect. No need to write a GUI yourself, but better to have a visual for documentation and review. Worked very well until we replaced EA with docs-as-code, now I miss that there is no nice simulator and Modeler for that workflow.
quietbritishjim 2y ago
State machines don't have a native syntax in C++ at all, so you can structure them however you want. It's easy to structure a state machine, if needed, so that all (or some) states can handle the same event in the same way.
- garethrowlands 2y ago
  Switch + goto is very close to being a native syntax for state machines. It's also very efficient.
- dgfitz 2y ago
  I always thought this framework was neat: https://doc.qt.io/qt-5/statemachine-api.html https://doc.qt.io/qt-5/statemachine-api.html Downside of course is now you have a dependency on qt.