This approach is a big boon to the development of complex UIs.<p>If you are tired of littering your React/Angular/Vue/etc code with a litany of state flags (“isLoading”, “isError”, etc)[0] take a look at the de facto canonical state chart implementation for JavaScript, XState: <a href="https://xstate.js.org/docs/" rel="nofollow">https://xstate.js.org/docs/</a><p>It’s been a joy to work with and can replace other methods of managing state (i.e. redux) while constraining the behaviour of your UI to predictable states and interactions.<p>[0] <a href="https://dev.to/davidkpiano/no-disabling-a-button-is-not-app-logic-598i" rel="nofollow">https://dev.to/davidkpiano/no-disabling-a-button-is-not-app-...</a>
People who gloss over this do so at your own risk. This technique is applicable for so, so many applications - even when it doesn't appear obvious at first.<p>Factoring out complex control system logic into these (and related) formalisms dramatically enhances testability, substantially reduces code volume, and eliminates huge swaths of possible defects (not to mention seriously enhances formal verification and model checking). The "code" part for applications should basically be for data plumbing, and all decision-making and control logic should be factored into these.<p>Thanks for posting this!!
There is an edX course by David Harel (the author of this paper) and Michal Gordon called <i>Programming for Everyone – An Introduction to Visual Programming Languages</i>. I highly recommend it for anyone dealing with state, whether you’re a programmer, designer, engineer, or manager.<p><a href="https://www.edx.org/course/programming-for-everyone-an-introduction-to-visual" rel="nofollow">https://www.edx.org/course/programming-for-everyone-an-intro...</a>
Harel's recent work (which evolve from Statecharts) is so called Scenario-based programming. If interested I follow his work very closely and showcase his techniques in this article about bthreads: <a href="https://lmatteis.github.io/react-behavioral/" rel="nofollow">https://lmatteis.github.io/react-behavioral/</a>
When I first saw Statecharts I failed to realize that Statecharts are _NOT_ state machines, state machines are the building block.<p>Quote from the paper:<p>"... a complex system cannot be beneficially described in this naive fashion [state machines], because of the unmanageable, exponentially growing
multitude of states, all of which have to be arranged in a ‘flat’ unstratified fashion, resulting in an unstructured, unrealistic, and chaotic state diagram. To be useful, a state/event approach must be modular, hierarchical and well-structured. It must also solve the exponential blow-up problem by somehow relaxing the requirement that all combinations of states have to be represented explicitly."<p>So regular state machines are usable up to only a few states and transitions. Implementing the whole set of Statecharts features is far from the quick exercise of building an ad-hoc, implicit state machine. Fully using Statecharts introduces some overhead. But the true power of Statecharts shows when using hierarchy, parallel states, history and so on, things that build on top of state machines and take a bit more investment to learn how to use.<p>--<p>Another interesting aspect is the "formal semantics". Quote:<p>"The statechart formalism turns out to be quite a challenge when it comes to providing formal semantics ... The main difficulty is not in the depth of states or the orthogonality constructs themselves; ... The more difficult problems arise with the introduction of events and conditions that are generated within the statechart itself, and are sensed in orthogonal components."<p>So the idea is that given the same Statechart diagrams, two different implementations should end up in the same states when subjected with the very same sequence of events.<p>Perhaps this is less of a problem to build GUIs and other applications that don't have super stringent requirements on safety and verifiability.
I have mixed feeling about the hierarchical facility in statecharts. I've certainly found it helpful in some cases; for example, handling "cancel" events that apply to a group of states.<p>I've also seen huge, multi-level, multiple-parallel-region monsters that were impenetrable.<p>Now, no formalism is immune to abuse: "just because you can, doesn't mean you should". But I've often found that the simpler state model formalism - without hierarchy - has led to cleaner design and better separation of logic.<p>More generally though I do think state machines are somewhat underrated tools in the programmer's toolbox.
A modern elaboration is <a href="https://statecharts.github.io/" rel="nofollow">https://statecharts.github.io/</a><p>- very clear explanation of statecharts, and why you'd want to use them (they're an elaboration of state machines)<p>- and why you <i>wouldn't</i> want to use them<p>very interesting, thanks to OP!
I've found xstate invaluable for multi-step flows on the front end.<p>Redux and similar libraries are a bit hard to read when making these because representing sequential distinct states is implicit. I.e., have an enum for the "page" and some reducer cases to update the page.<p>With xstate, the order of things is often visually apparent. Not only are distinct states bread-and-butter for statecharts, the machine definition in the code visually jumps out at the reader and screams "these are my states, and here's how to move between them!"
I quite like <a href="https://sketch.systems/" rel="nofollow">https://sketch.systems/</a> as a tool for quickly getting up and running with Statecharts.<p>There's also a good article by Hillel Wayne about using Statecharts and Alloy to formally specify UIs.<p><a href="https://www.hillelwayne.com/post/formally-specifying-uis/" rel="nofollow">https://www.hillelwayne.com/post/formally-specifying-uis/</a>
I have no idea why in university we covered state machines so very little when they solve a host of problems and can replace fundamental ways in designing software. Not only that but it's also compatible with them all.<p>I finally tried using state machines in a hobby project and its much better than just writing a bunch of if then statements in a event loop.
Was also inspired by the Statecharts long time ago, and then saw an opportunity to go deeper into how server-side web applications could be implemented as state machines, and how it would ultimately lead into easier/faster programming where correct/complex patterns emerge from events, conditions, and actions. Wrote about it here: <a href="https://jarirajari.wordpress.com/2014/01/03/ecas-hierarchical-aspect-state-machine-aka-ecas-hasm/" rel="nofollow">https://jarirajari.wordpress.com/2014/01/03/ecas-hierarchica...</a>
In the SwiftUI app I wrote recently, in an act of desperation, I dusted off my Harel statecharts skills (I used to develop tools like this), and ended up with a huge comment block with an ASCII-art hierarchical state model. Then the code structurese were based on that, and the names generally matched up between code and diagram. The app UI has been solid, even though some of the states are in the canned NFC UI mode, and less in my control.
I've worked in the past with code bases that have what were called 'state machines' implemented with at best switch statements and at worse a lot of if's and else's and some state variables.<p>I've also worked with code bases with a formally defined state machine object/concept, with pre-defined states, events, and state transitions driven by events.<p>Question for the crowd: what would you call the non-state machine state machine in the first case?
Back in university, I had a course on reactive systems, a whole semester of state machines and statecharts. I can't stress enough how useful it was in my career.<p>I've retrofitted some near unmaintainable embedded systems, and one of the easiest ways to improve spaghetti code is refactoring some of the vars into state machines/statecharts.<p>Btw, state machines play well with event sourcing and clustering.
I'm getting a flashback from Sproutcore JS statecharts, wish I could say they were good times but I'm so glad I'm not developing with them anymore.<p><a href="https://guides.sproutcore.com/getting_started_2.html" rel="nofollow">https://guides.sproutcore.com/getting_started_2.html</a>
Relevant: <a href="https://en.wikipedia.org/wiki/UML_state_machine" rel="nofollow">https://en.wikipedia.org/wiki/UML_state_machine</a><p>(Article references the above paper as citation #2).
Every graph can be represented by a 2-dimensional tree.<p>Hence, every chart in this paper has a 2-D tree representation.<p>You can write that 2-D representation, and then without any type of transforming (keeping the shape of the graph in tree form untouched), you can turn it into a 3-D statechart, via the use of a Tree Language (<a href="https://jtree.treenotation.org/designer/" rel="nofollow">https://jtree.treenotation.org/designer/</a>)<p>So you get a 2-D text encoding of the statechart, editable in any dumb text editor or spreadsheet, isomorphic to the visual circles and lines diagrams they have, just as a 3-D rendering.<p>You could probably put that in a paper.