Out of the Tar Pit (2006) [pdf]
curtclifton.net
curtclifton.net
Statecharts address head on both major sources of complexity: state and control.
Statecharts also enable 100% white box testing (called "informal reasoning" in the paper) in a properly-coded system (no backchannel state contamination).
When statecharts aren't applicable, I drop down to functional approaches (pure functions).
When that's not viable due to performance, I use algorithmic subsystems with a tiny API and the possibility to verify the system fully after each call. Then I fuzz test the shit out of it with full verification enabled and fix any bugs I find.
Maybe I took something completely different away from the paper that other people did.
One was that the whole thing was based on argument, not evidence, or even examples.
The other was that it seemed to match up the "web architecture", almost exactly. They advocate functional programming, and using relational calculus.
That is exactly how the web is structured -- a CGI script is essentially always a pure function. And then a SQL database is based on relational calculus (more or less).
I don't believe they mentioned that anywhere in the paper.
But I do believe that the web's programming model is a big part of what made it popular. A lot of programmers seem to complain about the lack of state in web apps, and will create elaborate Rube Goldberg contraptions to try to reintroduce it. But I think it's actually a good thing, and they don't understand the benefits of the archtitecture (scaling, among other things).
I find a statechart-based system to be just as understandable and testable as a pure function, and yet all it handles is state and control -- the supposed source of complexity!
I think you've also hit on why the web has been able to scale as well as it has. Scaling state is really, really tough.
I've seen custom state machine compilers for tricky code (not limited to parser generators)... but I don't have much familiarity with the term "state charts".
I find functional code goes a long way... a lot further than most people think. And then I try to capture all side effects in objects instantiated in main(). That makes them easy to isolate and scale later.
I like some of their arguments about relational modeling vs. hierarchical modeling... not sure about the implications in my own code yet.
Werner Vogels has a pithy headline "Life is not a State Machine"... I think too many people have yet to internalize that. An individual program is always a state machine, but a distributed system is not in general. You can force it to be one by using full Paxos everywhere, but that's limiting yourself to a very narrow subset of all possible distributed systems.
So there is something fundamental about state machines and scaling. There is probably an impossibility result somewhere about this.