Re:Mu: making programs easier to understand in the large
by dman on Saturday February 13, 2016 @08:21PM
(#11096631)
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.
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.