31–40 of 91 posts
Hierarchical state charts have been formalized as a type of UML diagram. Details: https://en.wikipedia.org/wiki/UML_state_machine
"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.
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.
More recently, I avoided some early SwiftUI bugs by modeling some of the iOS app interaction using Statecharts, in an ASCII art comment in the code, and implementing that.
> It’s easier to understand a statechart than many other forms of code.
There's a lot of arguable quantifiers here, but when I was started at https://gadget.dev (no longer working there), we started with hierarchical statecharts as a way for users to specify their behaviour (with the ability to customize transitions with code snippets). No matter what we did, users just found it incredibly confusing. This was with a customer based that had decent spread across the "how technical are you" spectrum.
Did we do a poor job of introducing it to the user? Maybe. We were forced to switch everything over to flat code though.
> As complexity grows, statecharts scale well.
I think there's a big asterisk on this one, likely. I had to undo a lot of unfortunate statechart code that was introduced for some of the backend of gadget, and I consider myself a pretty good programmer. Perhaps it's just the difference in paradigm, or the accidental complexity of how we worked with xstate, but I reduced 1000+ lines of very hard to read and extend statechart code to a few hundred lines of imperative code, with some hardcoded states. It was actually easier and faster for me to do this than fix bugs that existed somewhere in there (I tried, and failed).
Every engineer at the company (it's a small company :P) agreed that it was substantially easier to read and understand.
I think this perhaps echoes things said elsewhere here, like dflock's comment on the boundary between "xstate" and "not xstate".
All that being said, I'll restate: I love the idea of statecharts, I just have scars from dealing with them. I think they were perhaps applied in situations where the benefit was low, and the overhead of understanding the bits and bobs of xstate was too high of a cost for any perceivable benefit it may have offered.
> It’s worth noting that you’re already coding state machines, except that they’re hidden in the code.
I will say that this is a great point that may often be overlooked.
When I interview candidates, one problem I enjoy doing (and they do too!) is "let's try building vim" problem. We build out a few basic commands — move left, move right, replace character under cursor — to edit a string of text. The candidates that do the best often see how parsing can be encoded in a state machine and plan with that in mind. They perhaps still just encode it as if/else statements with a state variable, but that still gives the better outcome. Something like this:
0-9
---------
| |
| v hj
|-- (number N) -----> move N spaces
|
| r
------> (read char c) ---> replace N characters with c
The title contains hierarchical, which does not come back in the post. You probably need hierarchy, otherwise state charts become unweildingly large.
A statechart without hierarchy is just a state machine. It's the composition and hierarchy that turns a state machine into a statechart.
I wonder if it's possible to combine statecharts with durable execution engines like Temporal, DBOS, Restate, etc. At work we use Cloudflare Workflows for managing onboarding and payment workflows. It generates flowchart diagram that is useful for quickly reasoning about what the workflow does, which I guess is what statecharts is trying to achieve.
When you say "it generates flowchart diagrams…" what exactly is generating them? Is it built into cloudflare workers or is it something your team created?
Glad to see statecharts still getting attention! I created XState, a JS/TS library for authoring, executing, and visualizing state machines/statecharts: https://github.com/statelyai/xstate I've been working on it for 10+ years. The main thing I've learned is that statecharts are most valuable when they're treated as executable behavior, not just documentation. That doesn't mean you need to use them everywhere or mode…
Earlier quoted context omitted.
A statechart without hierarchy is just a state machine. It's the composition and hierarchy that turns a state machine into a statechart.
Is the very first example not one without hierarchy and thus just a state machine?
> A statechart is a state machine where each state in the state machine may define its own subordinate state machines, called substates