[empiricus]

"No statechart will survive contact with real world applications". I mean, when you have external dependencies, multilayer protocols, multithreading, perf requirements, the state will becomes an ugly mess. One can only dream of a clean statechart.

[hogehoge51]

Hierarchical state machines are common in hardware development. I've also used them for embedded systems, and dug my way out of spaghetti nightmares in distributed systems by reworking a system into a set of state machines.

Is it clean? Not always, it gets messy. On the other hand it is deterministic and traceable to specifications. Specifications as state machines can be easier understood and shared than raw code or raw prose.

I also think more effort is needed to synthesize a clean set of state machines with hierarchy for a system at scale and I'm sure there are times when that effort is not warranted.

[sghiassy]

I’ve used state charts in multi-billion legacy apps and they’ve stayed quite clean.

Just don’t use one state chart for everything. Just like any data structure, use multiple of them scoped appropriately

[01100011]

Sometimes the complexity is unavoidable and you have to pick the lesser of many evils. Oftentimes complexity management is trying to model the system in such a way that the complexity moves to the area which is most easily understood. It doesn't make the system less complex, only easier to reason about and maintain. State-oriented design is just a (very powerful) tool in the toolbox.

Even when I haven't actually used a state machine, I've modelled problems as state machines just to help me think about the system. Thinking in terms of state can often help traditional software designs.

[empiricus]

I agree, we try to think in terms in state machine. Just complaining that somehow this is not good enough, in practice we need to add random flags, and it is not clear how to separate the multitude of separate state machines all active at the same time.