I mention this in passing in the post, but I think the various notations that exist to express finite state machines help us greatly to understand complex softw

I mention this in passing in the post, but I think the various notations that exist to express finite state machines help us greatly to understand complex software systems. One way to express FSMs is the general node-and-arrow diagram. That makes sense for simple systems like a traffic light ("red" can only go to "green", etc. etc.) But for more complex state machines, we might want to express it in a regular expression, which is mathematically equivalent and lends itself to a different kind of mental model that might be better for, say, writing a search engine. Another "notation" to represent FSMs is matrices that model state transitions (if you can go from state 1 to state 2, X[1][2] = 1, otherwise it's 0, etc.) This is useful for certain other kinds of questions like "how many steps to go from state A to state B?. One practical use case of state machines is in parsing theory. If you're trying to parse JSON correctly to the spec, you might care about the formal grammar of JSON, which is often written in a specialized notation called BNF that describes what symbols can come after another. This is useful for implementing a parser, but to understand the grammar itself I personally find railroad diagrams [0] more intuitive. Different notations for the same idea let us be smarter in different use cases. On a completely different track of ideas: you might be interested in the work from Dion Systems [1] which are doing some interesting research into more dynamic ways to work with source code that I think reflects a lot of the ideas I wrote about. It touches on your specific comment more directly. [0] https://en.wikipedia.org/wiki/Syntax_diagram https://en.wikipedia.org/wiki/Syntax_diagram [1] https://dion.systems/gallery.html https://dion.systems/gallery.html