
Out of the Tar Pit (2006) [pdf] - erichocean
http://curtclifton.net/papers/MoseleyMarks06a.pdf
======
erichocean
I just found this paper (great, BTW). I've been using Statecharts ever since I
discovered them in the late 90's with great success.

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.

~~~
chubot
I read this paper over a year ago... but where does it talk about
Statecharts??? I searched through and don't see that.

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

~~~
erichocean
It doesn't talk about statecharts, but statecharts are a great alternative
solution to the problems it raises.

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.

~~~
chubot
Any pointers/examples on using state charts?

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.

