I've been studying state machines and specifically statecharts (which are essentially state-machines with hierarchy) for a while now. Here's a great resource to learn more https://statecharts.github.io/
I absolutely fell in love with them and haven't looked back ever since I learned more about how they work. As the author explains in this post we're implicitly writing state-machines all the times in the form of code. The idea of making them explicit, rather than implicit, helps us visualize the behavior which would've otherwise been hidden in code.
State machines have been the bread and butter of embedded systems for a long long time. Many years ago we used statecharts as a basis for a machine controller for a complex machine and the result was extremely robust. It's very hard to forget to handle something when you're working with this model. The downside though was that didn't have code generation tooling and whenever we wanted to make a change we had to change the visual statechart and then go to the code and make the changes there which was a bit of a pain. If you have the right tooling though that becomes a lot easier.
Because state machines are a weaker computational model they are easier to reason about, you can prove things on state machines you can't prove on a general program, you can do things like state minimization etc.
>I absolutely fell in love with them and haven't looked back
Same for me. In university you really just a get a taste of them, usually limited to one section of a design patterns course. But man, for certain cases they really make it easy to reason about complex workflows, that otherwise would be buried in generic flow control statements spread across multiple classes, or modules. In our app, there was a flaky and bug-prone area. It wasn't always like that. It started very simple but as feature grew the workflow become more complex. Anytime someone added anything related to that module it almost always broke something else, or introduce a leak that we found 3 months later. It was an area where you really had to focus whenever you made a change and even code reviews would miss it.
It took me about a week to document the implicit state machine, another week to roll my own state machine implementation tailored for that component, and one more week to refactor the code. It's been 5 years, our dev team tripled in size and it's been probably the most rock-solid module in that time. I'm not worried that some junior dev will introduce some esoteric regression issue downstream.
I've seen executable state machines (via UML) adopted in a few large companies that thought they could cut out all the boilerplate and increase productivity. But, they didn't realize the same level of effort would go into getting the behavior with edge cases nailed down. Then you were fighting a tool to get the last few bugs details worked out. Ultimately we saved no time and alienated developers.
This could potentially save me a lot of time. Thank you very much! Just recently I was involved with a project where what I did was essentially coding up a complex state machine complete with guards and in a way events.
Plenty of other stuff I have worked on would have benefited from this as well.
Plenty of stuff I am going to work on in the future will benefit from this.
Hey! I'm the creator of xstate: https://github.com/davidkpiano/xstate - a pure, functional, declarative implementation of statecharts in TypeScript. It has zero dependencies, is frameworkless, and fast (O(n) state and transition look-up time for most cases).
I have some important updates to announce at JSConf Iceland, including the ability to translate to/from SCXML, and an improved visualizer.
Though you should always have NIHS in the back of your mind, state machines aren't very difficult to implement which means when you write yours you can really tailor it to your use case.
I absolutely fell in love with them and haven't looked back ever since I learned more about how they work. As the author explains in this post we're implicitly writing state-machines all the times in the form of code. The idea of making them explicit, rather than implicit, helps us visualize the behavior which would've otherwise been hidden in code.
I'd highly suggest to also read this paper by David Harel, the creator of statecharts, On Visual Formalisms: http://www.wisdom.weizmann.ac.il/~harel/SCANNED.PAPERS/Visua...
If you're a frontend developer checkout my post on the subject related to React and Redux specifically: https://medium.freecodecamp.org/how-to-model-the-behavior-of...