[HN Gopher] Facts about State Machines
___________________________________________________________________
Facts about State Machines
Author : zdw
Score : 33 points
Date : 2022-09-29 18:59 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| slevcom wrote:
| State machines are cool but they don't compose well out of the
| box. Behavior Graph let's you build a composable network of them
| so they become a practical software architecture. (Disclaimer, I
| am a coauthor) https://github.com/yahoo/bgjs
| jayd16 wrote:
| Why not? Don't they compose easily with sub-state-machines?
| dqpb wrote:
| This is an excellent write up!
|
| > Combinatorial explosion can be mitigated through nesting and
| parallelizing
|
| You can also often just add an intermediary state to handle this.
| Instead of NxN you can have Nx2 by doing N->I->N.
| michaelsbradley wrote:
| Statecharts (hierarchical state machines) for the modern web:
|
| https://github.com/statelyai/xstate#readme
|
| https://xstate.js.org/
|
| Interactive visualizer: https://stately.ai/viz
| Jtsummers wrote:
| In a similar vein: https://sketch.systems
| michaelsbradley wrote:
| I'm not too familiar with Sketch (have seen the name, maybe
| visited the site previously) but is the focus comparable, and
| how so?
|
| Independently of XState's visualizer and more recent
| IDE/plugin offerings, XState allows you to declaratively
| specify statecharts and fsms (vanilla JS object notation),
| define handlers (functions) for transitions and services, and
| then instantiate those machines via an interpreter. It might
| not be fun to do all that, say, in a Node.js REPL, but you
| could.
| renlo wrote:
| Can someone recommend a good primer on _implementing state
| machines_? I've only really encountered the theory and the
| diagrams, but have had a harder time finding examples of actual
| implementations in code.
| alain94040 wrote:
| The primer is simple: if you notice that your code is using too
| many _if_ statements, especially nested ones, and you are
| starting to wonder if you are covering all alternatives and
| cases, then using the rigor of a state machine may help.
|
| You know, _that_ kind of code: if(start) {
| if(!running) ... } if(stopped & !jumping) {
| } else if(running) ...
|
| Stop and write a proper case statement (aka a state machine).
| You may discover that combinations of booleans (in my example,
| stopped & !jumping) deserve to be their own state. The insight
| is that the resulting code should be one clean case statement,
| with no nested ifs allowed. Then you know you cover all the
| states/cases.
| rowanG077 wrote:
| It really depends on your programming language. In C it's not
| much more then a switch case over an enum where every enum
| value is a concrete state. It languages with pattern matching
| and ADTs it's much more ergonomic since a state machine then is
| just a function from a state and an input to a new state and an
| output.
| jayd16 wrote:
| Not sure I necessarily agree with all these. Its common in game
| programming to use a form of state machine that defines a
| character's animation. Characters can be in an idle state, an
| attacking state, a hit-react state. Because its desirable to have
| the animations blend, the state machines transitions are not
| atomic.
|
| Now, you could argue that this design is not a state machine but
| I think its more useful to understand that such a thing that is
| VERY similar to a state machine but has non-atomic transitions
| does exist and is commonly used.
| murderfs wrote:
| That just means that the actual state machine has intermediate
| states for each transition.
___________________________________________________________________
(page generated 2022-09-30 23:00 UTC)