FSL: A programming language to make complex finite state machines easy to create

Well, there's like 50 others, many of whom are in heavy use in industry, so, I guess I feel like a lot of people think this is useful.

.

> I feel like Erlang is already a great language — almost a DSL — for “making complex finite-state machines easy to create.”

Erlang is almost my favorite language.

I've tried using both of its finite state machine libraries. I do not find them to be usable. The results are extremely verbose, and if one goes over around 30 states, I cease to be able to debug them.

The natural implementation of the TCP/IP state machine in FSL is eight lines; 315 bytes. The TCP/IP Erlang state machine example floating around is like ten times that size.

I find debugging that thing exhausting.

.

> It’s very easy to write a static analysis pass to verify that a primitive Erlang module like this constitutes an FSM “and no more”

It's not clear to me why you would want this

.

> Honestly, ignoring all the stuff about concurrency, Erlang source code / BEAM bytecode is an almost perfect abstract machine for reifying various computational formalisms

It can't implement anything without Okasaki juggling. You and I are in strong disagreement here.

FSMs are a great example. You either need to reach outside the Beam VM with `hipe_bifs:array` or you need to copy the entire machine state every time you want to mutate it.

.

> And, if I were implementing something like Cloudflare’s Edge Workers “but for FSMs”, it’d be an extremely easy decision to standardize on (a restricted, static-analyzed at submit-time sub-ISA of) BEAM bytecode.

At Cloudflare's scale, the inability to implement mutably would become a serious performance problem.

I just posted some youtube videos I enjoy to make sure the build toolchain was placing youtube videos correctly.

Obviously, as the author of one of these things, I'm a pretty big fan of FSMs. And, y'know, even though the entire point of mine is to be easy and convenient to use, I still don't use it very often.

Most jobs aren't for FSMs.

Finite state machines aren't well applied everywhere. There are a lot of cases where you could use a finite state machine, but shouldn't. A chess board is an example: it is a well described state, there's clear right or wrongness to changes, there's no ambiguity or intermediate states, etc. However, managing a board that complicated, dealing with rules like en passant and castling, it'd be a hassle. You don't get enough value out of it, and so it doesn't matter what you're using. Yes, FSMs can handle chess; no, it's not a good choice IMO.

But then, there are times when it's well applied.

When it's something where an FSM is a good choice, and you've used a low-hassle library, my opinion is that they tend to make systems night-and-day simpler.

Consider creating a finite state machine for the state of any single given payment. Now, when the external actor changes their process, the FSM wedges and you get notified, instead of switching to a state that used to be impossible and isn't anymore, in software that isn't ready for that. That's a huge level of immunity to large classes of bugs.

My opinion is that FSMs are well applied when the cost of a state reaching a bad configuration is very high.

You wouldn't use them to manage the image in a paint program.

You would use them to control the airplane's jet being on or off.

If you're in a situation where they're well applied? Now it's going to matter a lot which system you actually use.

I have great respect for `xstate`, by example. It doesn't fit my preferences, but it's fast, robust, and largely bug-free. It's reliable, easy to work with, well documented, and has a good solid community. If you use `xstate` you'll have a good time, most likely.

By contrast, at a previous ruby job, we used a gem I'm not going to name. It was ahem not my favorite. It was slow, it was pretty easy to get it wedged when it shouldn't be, it relied on side state things as storage that weren't fundamental to the language, it was cryptic when it failed, et cetera.

Later, at that job, we switched to a different state machine gem. It was pretty hassle-ful; the datastructures needed to be manually converted because there was a slight difference in how the two gems saw the job which meant automatic conversion wasn't practical.

But we were sure glad we did! Once the other FSM library was in place, things were a breeze, the system was much easier to understand, and to control.

There's more to it than good or bad, though.

If I couldn't use my own, what would I use?

If it was business logic, I'd probably use `stent`. To me it's the easiest to debug, and seems the most robust. Their tracing tools are quite impressive.

If it was a redistributable react control, I'd probably use `fsmx`, or embed a cut-for-case one. Stent is 288k. FSMx is 24k. If it's typescript, I'll probably use `fsmachine` instead, which is 28k.

If I need transactionality, `edium` is my only real world choice.

If I need something that's easy for junior programmers to understand, I'll probably use `javascript-state-machine`.

If I need something to create documentation that's easy for non-programmers to use, it's very likely to be `state-machine-cat`.

And of course, if I could use my own, I'd prioritize it when doing less labor or having a shorter representation of the machine is better. For me, that's pretty much always shrugs `xState`'s light switch is 13 lines; `jssm`'s is a one-liner that's shorter than `xstate`'s import.

So.

What I would recommend is that you pick one that graphs for you, like `stent` or `xState` or `jssm` or `state-machine-cat`, and just try drawing out a rough of your business logic.

Maybe it's well implemented in a state machine. Maybe it isn't.

But once you've tried, it's usually pretty obvious which one it is. And it can be fun to try, y'know? New languages are neat.

If you have a bunch of little moving pieces that follow complicated rules and can't be wrong, there's a pretty solid chance that state machines are for you.

They're one of those tools that the right time isn't common, but when it is the right time, holy WOW do you want them

David has done a better job of making a nice setup. His tooling is cleaner. `xState` is slightly faster than `jssm`. `xState` is much more widely used than `jssm` (several orders of magnitude,) meaning that it is more trustworthy. He has more tutorials. He has more community. His documentation is not literally on fire.

I believe that my testing is significantly better. My library offers more features, including some fun exotic stuff like stochastic search. Whereas we both offer datastructure consumers (and they're similar,) I also offer a string DSL that is regularly 1/20 the byte count of the datastructure implementation. Terseness matters a lot to me. My typescript support is better. I have a live editor which I find has high value for understanding and debugging.

I guess in my impression, my biggest thing is the string language (super dense, super easy) and his biggest thing is his community (you can ask people questions)

Otherwise, in my impression we're quite similar. We both offer all the standard things; we both offer a visualizer; our visualizers look pretty similar because they're built on similar underpinnings.

Being honest, I'd say he's winning. But, not by much, and there are clear reasons to choose one over the other according to preferences, so please try both.