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

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 https://github.com/notduncansmith/factfold