I love statecharts, but I wanted to challenge some of the "why"s in this post.

> 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

[EDIT] And I should say, I _am_ repeating some of what's stated in the linked site (under "Why should you not use statecharts?")

user:	gedge
created:	June 3, 2021
karma:	11
about:	https://gedge.ca