One thing usually skipped in primers: history pseudo-states (H, H) make a statechart formally non-deterministic from outside. The pitch is "current state is a pure function of inputs" — history breaks that. Entering a parent via `H` puts you in whichever child was active last, so the same event from the same outer state can land you in two different inner states. That latent "last-active child" IS state, just state nobody draws on the diagram. Harel's original paper acknowledges it; SCXML and XState both implement it; nobody really talks about it. So if you're using deep history (H) to preserve subtree state across re-entry, you've moved the bookkeeping into the chart engine — fine, but the picture alone no longer tells the full story, and history transitions need their own tests like any other piece of state.
Statecharts: hierarchical state machines
51–60 of 91 posts
Re: Statecharts: hierarchical state machines
#52I'd like to see a computer language where statecharts are primary control flow construct and ECS are primary data structure.
Re: Statecharts: hierarchical state machines
#53I'd like to see a computer language where statecharts are primary control flow construct and ECS are primary data structure.
P lang is close: https://github.com/p-org/P
Re: Statecharts: hierarchical state machines
#54Hierarchical state charts have been formalized as a type of UML diagram. Details: https://en.wikipedia.org/wiki/UML_state_machine
I think it's either "hierarchical state machines" or just "statecharts", otherwise it's a bit like saying ATM machine or CC card.
Perhaps, but I object to the "machine" phrasing. Ordinary finite state "machines" (without hierarchy) aren't machines either, they are just diagrams of something that could be a machine or something else.
Re: Statecharts: hierarchical state machines
#55Earlier quoted context omitted.
I think it's either "hierarchical state machines" or just "statecharts", otherwise it's a bit like saying ATM machine or CC card.
Perhaps, but I object to the "machine" phrasing. Ordinary finite state "machines" (without hierarchy) aren't machines either, they are just diagrams of something that could be a machine or something else.
They're diagrams of something that does something, otherwise it's just a rectangle. And once it does something, isn't that kind of an abstract machine anyways?
Re: Statecharts: hierarchical state machines
#56I've tried to use state charts for frontend development a couple of times, but bounced off. IIRC, I was using xstate with vue, and I found that they were hard to retrofit to existing systems, and where I tried, I found that the boundary between the part of the system controlled by xstate and the rest of the system problematic. It felt like it would work better with everything "inside" the statechart, but that's a big…
Out of curiosity, was that before or after LLM agents?
Re: Statecharts: hierarchical state machines
#57Since the state chart itself doesn’t contain any data, I’m wondering where the data lives and how you handle data that’s only valid in certain states? It seems like having the states separated would be rather awkward versus, say, a TypeScript union type that keeps them together?
Re: Statecharts: hierarchical state machines
#58Anyone remember Sproutcore JS? They used state charts.
Re: Statecharts: hierarchical state machines
#59While we are discussing state charts and source code generators, Qt deserves a honorable mention with it's Qt State Machine framework
https://doc.qt.io/qt-6/qtstatemachine-overview.html
Qt also supports W3's State Chart XML (SCXML)
Re: Statecharts: hierarchical state machines
#60I've tried to use state charts for frontend development a couple of times, but bounced off. IIRC, I was using xstate with vue, and I found that they were hard to retrofit to existing systems, and where I tried, I found that the boundary between the part of the system controlled by xstate and the rest of the system problematic. It felt like it would work better with everything "inside" the statechart, but that's a big…
Out of curiosity, was that before or after LLM agents?
Before. I could, probably, now get an LLM to refactor everything to be inside the statechart - but I'm not sure if I actually want that.