Hacker News Reader

Comment by notduncansmith | Hacker News Reader

State is typically multidimensional, so being "in" some state implies a whole lot of context (a whole lot of variables), and most real-world situations are so loaded with context that the only unambiguous way of determining which real-world variables are represented within your program is reading the code (or inversely, any unambiguous definition of which real-world variables are relevant to your program may as well be code). This limits the value of statecharts IMO. I think a more useful solution is something that describes how each level of state is derived from the previous level.

View on HN

Of course to understand how things are implemented you'll have to read the code. With statecharts at least you have a visual bird's-eye view of the behavior of your UI. This is important because otherwise you'll be lost with just code to figure out how things behave.

More importantly, statecharts limit your behavior - a specific state can only go into another state if there's an outgoing arrow. This limitation is quite awesome because, given any state, you know that the only thing effecting change are the transitions - nothing else!

Also I want to stress the importance of the unclustering property described in the paper. Your high-level statechart can be a simple diagram. Then you can "zoom in" and see the behavior of other portions of the diagram. This is quite powerful abstraction and I don't see how "just code" can solve this - especially because we're inherently visual creatures.

I'm definitely not arguing against the statechart being higher-level than a pile of state mutations. I think they're very low-resolution however, and I believe there can exist code that can serve the same high-level purpose as statecharts without discarding as much information.

I also think zoom is a very powerful visual metaphor for context, and I don't mean to discount the value of that. I just think the contents of each node in the zoom-context graph could be higher-fidelity.

> More importantly, statecharts limit your behavior - a specific state can only go into another state if there's an outgoing arrow. This limitation is quite awesome because, given any state, you know that the only thing effecting change are the transitions - nothing else!

This touches on a point that I think is important and would like to expound upon.

One thing that makes code easier to reason about is "locality", being able to see everything that affects what you're looking at.

One way of dealing with poor locality in code is to zoom out until you're only looking at a web of state transitions, and then you can find the state you're in and see where you could have come from (which offers hints as to how you got there) and where you could go (which offers hints as to what might happen next).

Another approach is to write high-locality code, code which describes the incoming arrows so that by design, whatever you're looking at is already revealing its composition, and fractally-organized at that. That can be hard to do in application code with existing tools, although (shameless plug) I wrote libraries to help make it easier in Clojure and Javascript: https://github.com/notduncansmith/factfold

Reply on news.ycombinator.com