I am in industrial automation and functional safety of machinery, especially complex sequenced machinery like burner management systems, mine winders bulk handling stackers/reclaimers/shiploaders, route sequencing for bulk handling/grain etc and architecturally this is very similar to the point I have gravitated to over 25 odd years of trying to find optimal ways of specifying highly predictable and reliable machine behaviour, with optimal code outcomes strong traceability back to the specification.
Basically state machines, but a little bit more, and a formal way of specifying them.
Eventually I got to the point where I built a package in PyQt that allows formal specification in a regularised way using a form of a "dynamic cause and effects" chart that at first glance looks a little like excel, per state machine. But it for the specification to be executable (so it is also a simulator you test run your code on as you developed your state machine/s to verify behaviour), could generate documentation programmatically and could also effectively directly write export files for the code for the target controller, if desired.
Originally it was a means to fully defined and predictable behaviour, and easily demonstrable traceability of requirements to acode, but it also turned out to be the sweet spot to bridge the world of, say, the combustion engineer who knew the general logic/steps in his mind but did not code, and the systems engineer coding the controller for a BMS system.
The combustion engineer got full control of specifying the desired behaviour and the systems cder only had to worry about implementing exactly what was specified into code for the safety PLC controller of choice. Often there is a large overlap there when the specification is by the traditional english language "crappy narrative" and there are endless TQs and functionality updates flowing backwards and forth.
Then I discovered there is an IEC standard related to distributed real time control architectures, where they are narrowing down on how to best specify and implement such schemes. But one of the core underlying essences is the executable specification, which they do by trying to go down the path of XML and OPC. You might like to check out IEC61499. But they are still working on a lot of details and last I checked there are only a few reference projects where they got it anywhere near right at scale and made it really work, but a workable framework seems to be emerging.
Based on my experience of real time controls, this state based methodology solves a lot of problems of randomly stateful code. For my work, you usually know if you got it right pretty quickly because you iron ore stacker or shiploader or burner system does not misbehave unexpectedly, though there can be latent issues in automation code that only come out in certain circumstances years later, but much less os with state based approach.
I'm aware of one case where over ten years later after delivery of some special controllers circumstances lined up and acode deficiency lead to a loss of well over a billion dollars for one of the biggest miners on the planet.
I think Cell lang is really something that could take off if enough people realise what it is and the benefits it might give.
But it needs a slightly different way of thinking about your problems and how to solve them in a way that best fits to the architectural framework that statefulness uses. Some people seem to take to it, some adapt poorly.
Because it lends itself to creating code that is effectively an engine and "configured" with data in the possible languages available on PLC type controllers, I've had some problems with a few ICS engineers who just don't get it and can only see the code as near meaningless.
First time you build a larger dynamic system out a hierarchical state machine arrangement can be a little challenging, but you definitely get the hang of it, UML timing diagrams can be your friend.
But you can end up writing incredibly efficient code for the state machine approach, and for each machine you can only be in one state and only logic related to what state is currently executed and all outputs are a feature of state only (assuming Moore machines are enacted), so troubleshooting can be dramatically reduced as you have effectively encapsulation by architecture.
I look forward to seeing how Cell lang develops, I believe it has many, many advantages it might offer and has only just begun to yield some of the possible benefits. I believe it could also potentially be a new higher level language for real time and distributed controls/automation in the future if the standards committees can see past their nose, and ultimately be the language of choice for such applications, or something like it might be.
Final point, state machines lend themselves well to formal methods, so there is also possibility of a TLA+ transcriber from Cell to allow very painless formal methods verification of things like, all states can be reached, and all states have an achievable exit transition condition, and so on. Real time guys love this sort of shit when it matters (aerospace etc) and really everyone should at some level.
Final wish : I would like to see a an XML interface that allows translation in and out, even if only for a key restricted set of the language, but it doesn't look too hard and could open up a world of interfacing to existing tools of various kinds, a lot of ICS and real time engineers love to exchange interface and functionality data in XML if there systems are organised to use it.
