| ▲ | throwaway2037 13 hours ago |
| > riddled with state machines
Why is this bad? Normally, state machines are easy to reason about. |
|
| ▲ | majormajor 13 hours ago | parent | next [-] |
| 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!" |
| |
| ▲ | kayo_20211030 20 minutes ago | parent | next [-] | | I have a coding problem. I'll use a state machine! Now, I have two problems :-( | |
| ▲ | throwaway2037 12 hours ago | parent | prev [-] | | 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? | | |
| ▲ | bvrmn 4 hours ago | parent [-] | | Like properly model a domain in domain terms? | | |
| ▲ | nottorp 3 hours ago | parent [-] | | And that won't be a state machine with the states having more fancy names? | | |
| ▲ | InDubioProRubio 2 hours ago | parent [-] | | It will be, but the idea of having an overview over the states is gone then. There is just modules-> objects with the transitions being method calls. Nobody will have to know all the things about all the state transitions, resulting in another problem (dys)solved by architecture obscurity. If needs be the state-machine can be reconstructed on a whiteboard by a team of five. |
|
|
|
|
|
| ▲ | risenshinetech 13 hours ago | parent | prev | next [-] |
| Please describe "normally". State machines can turn into nightmares, just like any design pattern used poorly. |
|
| ▲ | nurettin 9 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | lelanthran 2 hours ago | parent | next [-] | | > 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. I place a note at the top of my diagrams stating what the default state would be on receipt of an unexpected event. There is no such thing as "event silently gets swallowed because no transition exists", because, in implementation, the state machine `switch` statement always has a `default` clause which triggers all the alarm bells. Works very well in practice; I used to write hard real-time munitions control software for blowing shit up. Never had a problem. | | |
| ▲ | rramadass an hour ago | parent [-] | | > hard real-time munitions control software for blowing shit up. Never had a problem. Ha, Ha, Ha! The juxtaposition of these two phrases is really funny. I would like to apply for a position on the Testing team :-) |
| |
| ▲ | quietbritishjim 5 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | liontwist 3 hours ago | parent | prev | next [-] | | goto is exactly this feature. | |
| ▲ | a_t48 9 hours ago | parent | prev [-] | | I believe HSMs can model this, but don't quote me. :) | | |
| ▲ | nurettin 8 hours ago | parent [-] | | 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 5 hours ago | parent [-] | | 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. |
|
|
|
|
| ▲ | AnimalMuppet 13 hours ago | parent | prev [-] |
| 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. |
| |
| ▲ | lelanthran 9 hours ago | parent | next [-] | | > 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 20 minutes ago | parent [-] | | In fact state machines are great for documentation even if the code is not explicitly written as a state machine! |
| |
| ▲ | rramadass 9 hours ago | parent | prev [-] | | 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. |
|
