[lmm]

I disagree, I find state machines almost impossible to reason about. Has it already been through state X? Who knows. Will it come back to this state in the future? Maybe. Is there a route from state Y to state Z? Shrug. State machines are effectively goto writ large, and there's a reason we switched to structured programming.

[xedrac]

Well-designed deterministic state machines are incredibly easy to reason about. You simply render them as a graph and at a glance you can understand every possible transition and state.

> Will it come back to this state in the future?

If there's a path from the current state back to itself and it gets the correct inputs, yes. Otherwise no.

> Is there a route from state Y to state Z?

A simple glance at the graph will suffice to answer this.

Of course poorly written code, regardless of the constructs, will be hard to reason about.

[lmm]

> You simply render them as a graph and at a glance you can understand every possible transition and state.

But programming by editing graphs never caught on. So the graph is always going to be a secondary representation of your program; it won't be the natural view in your debugger or profiler (if it's even visible at all).

And more importantly, no-one's found a really compositional approach to programming with graphs yet. In conventional programming you can define an interface that exposes one function, and maybe you have an incredibly complex implementation behind that interface, but you can reason about the rest of your program without having to look inside that black box, even as the implementation changes drastically. I've never seen the same approach applied to state machines: maybe you know that this cluster of states is independent now, but anyone can add a new state transition that changes the global control flow willy-nilly.

[zackmorris]

I wish I could upvote you 100. State machines are fine up to some number of states, on the order of 10. Beyond that, they become incredibly difficult to reason about in real programs because each state may have side effects with program state.

What ends up happening is that exceptional situations happen and the state machine becomes muddled with special cases. So for example, say you're writing a networked game of Tetris or Pacman, something with a relatively small state machine. You get all done but realize that you forgot to handle people joining or leaving the game, or the game closing or jumping ahead when a remote player beats the level and the game needs to go back to the title screen. The state machine starts getting all of these checks interspersed with the game logic.

Typically this doesn't happen with sync/blocking code though. You write an ordinary main loop, adding checks for these exceptional situations just like any other event you watch for. In my experience, the sync/blocking code is roughly an order of magnitude smaller and easier to reason about than a state machine. But more importantly, it can be scaled infinitely, because you can always add tracing or step through it in a debugger as you normally would. But a large state machine is just exactly what you described: a large switch command of gotos. You can't just look at it and know where the code came from or what conditions got it there. You have to derive that history by hand in your head.

And since async/await is more conceptually equivalent to a state machine than a coroutine or sync/blocking code, that severely limits how well we can reason about large promise chains. See my comment to jcranmer on this thread for a bit more insight about the internals of this:

https://news.ycombinator.com/item?id=22731043

[lmm]

> And since async/await is more conceptually equivalent to a state machine than a coroutine or sync/blocking code, that severely limits how well we can reason about large promise chains.

I have to disagree with that. You can implement async/await using state machines, just as you can implement a loop using goto, but it's a more constrained model that's much easier to reason about than a fully general state machine or a fully general coroutine. The control flow still proceeds the way you expect - you still execute code from top to bottom, you still return once from every function call - you just yield at some points in it. You're not interleaving your control flow with some other function that you communicate with (like a generator), and you're certainly not treating suspended control flow as something to be copied or passed around (like a coroutine). It's a much simpler concept.

[ahasani]

What do you think about hierarchical state machine [1] ?

>Has it already been through state X?

Like everything else, logging

>Will it come back to this state in the future?

Mentioned in the comment before, there is a transition graph that you can do static analysis on, note that you might run into a halting problem

>Is there a route from state Y to state Z?

There is a transition graph

>State machines are effectively goto writ large...

quoting Prof Carl Hewitt of Actor Model, "goto is harmless"[2], function/procedure call is a goto, much like sending an named event while in particular state with/out parameters

[1] https://en.wikipedia.org/wiki/UML_state_machine

[2] https://www.youtube.com/watch?v=7erJ1DV_Tlo&t=34m54s

note: edited for formatting

[lmm]

> What do you think about hierarchical state machine [1] ?

Would need to see what the implementation actually looked like and how it was worked on. The graphs may look nice, but I've never seen people program effectively by editing graphs.

> Mentioned in the comment before, there is a transition graph that you can do static analysis on, note that you might run into a halting problem

Sure, but the graph seems to be very much secondary. You don't step through the graph in a debugger, for example.

> quoting Prof Carl Hewitt of Actor Model, "goto is harmless"[2]

Not at all convinced, and he fails to make any real case for it. I've worked on actor systems, and they're bad in the same way that unstructured code is bad.

> function/procedure call is a goto,

It's not, because you still have the call stack. You know where you came from and why (and can see it in the debugger), and you know you're going back there. You can reason compositionally, because in g(f(x)) f is a black box and always will be even if it gets refactored, whereas there's no equivalent "locality" in a state machine.

> much like sending an named event while in particular state with/out parameters

That also sounds like a bad way of doing things.

[ahasani]

Interesting points, thanks

> Would need to see what the implementation actually looked like and how it was worked on

Examples are but not limited to Simulink, Rhapsody, Unreal Blueprint, QT SCXML

>The graphs may look nice, but I've never seen people program effectively by editing graphs

graph mentioned is a state transition graph, not necessarily a visual graph, although its a nice eventuality

> You don't step through the graph in a debugger, for example.

Yes you do, if using the mentioned example

Combining a state machine with actor model has been a work wonder for me. I have to agree with you on locality in pure state machine, but if a state machine is defined as an Actor you get locality by definition. Its more of a deterministic abstract modelling, testing and execution

[lmm]

> I have to agree with you on locality in pure state machine, but if a state machine is defined as an Actor you get locality by definition.

Not really. You have a kind of binary version of locality - whether something is in the same actor or not - but you can't reason about any region that's smaller or larger than that. Incoming messages might arrive from anywhere, and emitted messages might cause any kind of effect anywhere (including other messages back to the sending actor). So you can't really understand any region larger than an actor without having to understand the whole system - and that's before we even get to passing actor addresses around.