81–90 of 91 posts
2. I did come across Tinyfsm (https://digint.ch/tinyfsm/). Any thoughts on that?
I blogged[0] a bit about my experience with Finite State Machines, and about the architecture we landed on with XState and Mastra (although since publishing we have swapped to Pipecat).
[0] - https://blog.davemo.com/posts/2026-02-14-deterministic-core-...
2 hours and not a single comment yet?! At one point, Statecharts seemed to be getting traction in the frontend/UI ecosystem, albeit tiny traction. Leveraging state machines (and particular Statecharts, which is basically compositions of state machines) for UI interactions makes complex flows so much easier to reason about! However, seems the traction eventually disappeared for unknown reasons, sadly. If this is the f…
Naturally, as the author notes, we are using states in our programs. Three kinds at least
- current program state in the complex space-of-states the program can have - most properties (and vars) are expect to undergo several states, and enumerable denotes a state. - every program traversing a graph for something, essentially runs a state machine of some sort
Indeed a user interface can benefit from having a FSM run it, given interfaces guide the end-user through predefined states from which he navigates into other states (which show/hide a set of widgets and wire them with data).
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…
nice thanks. been looking for a rust equivalent
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…
hm "inputs" can refer to just current and future inputs --- or it refers to the totality of inputs, including the inputs leading up to "here". in the latter interpretation the machine is perfectly deterministic. and the "deep history" pointer simply is part of the state machine.
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…
Going solely off your description of the scenario; couldn’t you trivially model any history (H,H) node as two nodes —> (A, H’) —-> (H’, H) —> (H, B), and have it be deterministic again I’m essentially thinking of H’ as a write-ahead-log prefixing any node
Earlier quoted context omitted.
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.
finite state machine (FSM) state charts (FSM with history pointers) pushdown automaton (FSM with a stack) turing machine (FSM with a tape) the terminology is well established.
Earlier quoted context omitted.
I’m not the GP, but I think petri nets are awesome. At least they’re a great way to represent and visualize many systems. Statecharts I find tricky by comparison. For a simple example, imagine you’re making a game and the player has to talk to three people in any order before moving to the next stage. this is very easy to represent as a petri net. (you just need three places and have a token in each one represent hav…
> But I think it corresponds to 8 separate states in an FSM (or statechart? not sure) In a conventional FSM yes but not a statechart. Statecharts support parallel regions within a single state. You’d have 3 regions for your example: one waiting for each person. There would be 4 states total: one to wait on each person, each in its own region, plus the superstate. The superstate would exit when all 3 “waiting for pers…