Hacker News Reader

Comment by sktrdie | Hacker News Reader

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.

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...

View on HN

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.

great comments on statecharts previously here https://news.ycombinator.com/item?id=15835005

the top few comments i find compellingly skeptical.

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

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

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.

Is there much in the way of FOSS statechart implementations? It's been a while since I looked into the ecosystem.

I remember that the canonical one was always the Quantum framework, but I never wanted to deal with the licensing aspect of it.

Definitely not FOSS, but Stateflow is used a ton in scientific computing (Automotive, Control Systems, etc): https://www.mathworks.com/products/stateflow.html

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.

Let me know what you think!

I think that looks awesome! Makes me wish I was a JS programmer so I could try it out :)

I use statemachines a lot in embedded systems and decorate the code with comments that are easy to translate into graphvizs "dot" languge.

Also played around with doing dynamic charts as the code runs, but stopped doing that as it was more novelty value than any other kind of value :)

Qt has QStateMachine http://doc.qt.io/qt-5/qstatemachine.html which is modeled after State Chart XML https://www.w3.org/TR/scxml/ (but no XML is required to use it)

It's LGPLv3 if you use Qt > 5.6 (LGPLv2 earlier), and 5.6 is getting old now.

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.

Statecharts are a very different beast than a traditional state machine. Putting together a good statechart implementation is a boatload of work.

Missed that part. You're correct.

JS Harel Statecharts: https://github.com/burrows/statechart.js

Reply on news.ycombinator.com