I don't need a compiler, I don't need to write optimizations.
You've effectively created a sort of portable assembly language, but it's more verbose than usual assembly language ("sub eax, 3").
but all that effort hasn't really translated into helping me understand the large-scale structure of random open-source codebases more easily.
I think the root of the problem is that software is being written to be more complex than it could/should be, so the solution is to encourage reducing complexity.
You've effectively created a sort of portable assembly language
Exactly. The verbosity is mostly because of my teaching project. I think teaching assembly can be just as ergonomic as teaching a high-level language. Indeed, most of us from a generation ago learned programming using assembly. It just needs to get a little more ergonomic.
the solution is to encourage reducing complexity.
Yup. The problem is that human beings have a _terrible_ track record at managing complexity. It's not just every software project ever; think about the creep of bureaucracy in ancient China, or the creep of legislation in ancient Rome. Everytime we've created a repository of rules it's gotten complex (and then gamed by smart operators). I think the problem is that it's very hard to justify removing a rule, so such repositories grow monotonically. The only way to periodically prune unnecessary rules is to first track why you created them in the first place (https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence). Hence: tests! I think they are the great advance bequeathed to the human race by software. And they're far more broadly applicable outside software -- though I have no idea how to do this applying. I wrote up some speculative ideas about it at http://www.ribbonfarm.com/2014/04/09/the-legibility-tradeoff a couple of years ago, but that piece isn't very clear.
While working on large code bases I have often (in half jest) wished for the concept of a runtime performance tax on code that is engineered poorly. Some variants of this could be
a. Imposing an exponentially increasing programmatic sleep on functions based on their length.
b. Repeated database / filesystem / network requests for identical resources multiple times in a program should again incur a slowdown.
You've effectively created a sort of portable assembly language, but it's more verbose than usual assembly language ("sub eax, 3").
but all that effort hasn't really translated into helping me understand the large-scale structure of random open-source codebases more easily.
I think the root of the problem is that software is being written to be more complex than it could/should be, so the solution is to encourage reducing complexity.