4 ms·

"No statechart will survive contact with real world applications". I mean, when you have external dependencies, multilayer protocols, multithreading, perf requi

"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 6mo ago
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.
- deleted 6mo ago
  [deleted]
sghiassy 6mo ago
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 6mo ago
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 5mo ago
  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.

hogehoge51 6mo ago

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.

deleted 6mo ago
[deleted]

sghiassy 6mo ago

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 6mo ago

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 5mo ago
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.