Confessions of an Abstraction Hater
Recently, I&#x27;ve been reading the TeX program by Donald Knuth, and some related programs. One the one hand, they are <i>intended</i> to be read (written using the “literate programming” style he developed), so they ought to be easier to read than typical programs (and maybe they are, compared to circa 1980 Pascal programs of similar size). On the other hand, I… struggle.<p>In these programs, Knuth uses very few abstractions. I think there are two reasons for this:<p>* These programs were written in the “standard” Pascal as of 1980, a language which had many limitations (see Kernighan&#x27;s essay on the topic) — and on top of that, Knuth wrote these programs to be as portable and memory-efficient as possible, across the many (often poor) Pascal compilers that were available to typical users at typical computer installations.<p>* To some extent, I suspect it is just Knuth&#x27;s style and preference. As a programmer who started his career writing assembly programs in his own style (a story from 1960: <a href="http:&#x2F;&#x2F;ed-thelen.org&#x2F;comp-hist&#x2F;B5000-AlgolRWaychoff.html#7" rel="nofollow">http:&#x2F;&#x2F;ed-thelen.org&#x2F;comp-hist&#x2F;B5000-AlgolRWaychoff.html#7</a>), even when given a supposedly “high-level” language, he probably thinks very close to the machine. Even as a mathematician (a profession often believed to be fond of abstraction), his style is characterized less by abstraction-building and more by deep attention to detail and “just do it”: he calculates constants to 40 decimal places; he does not stop at analyzing Big-O complexity (despite having popularized the notation) but finds the actual constant factor; he does not analyze on an abstract model of computation but writes assembly programs for a specially-designed mythical computer and analyzes them; and so on.<p>Nevertheless, his literate programming seems to be a way of solving the problems for which abstraction is often used as a solution (comprehensibility, etc), without introducing abstraction (and paying its cost): you can have functions that are hundreds of lines long, but presented in understandable (dozen-line or so) chunks.<p>Here&#x27;s an example from something I was reading today. Unfortunately to make sense of it you need to be somewhat familiar with the conventions of Pascal, of WEB, and the current place in the program, and turn off your instinctive horror of non-monospaced code and the weird (for today) indentation. (Some background here: <a href="https:&#x2F;&#x2F;shreevatsa.github.io&#x2F;tex&#x2F;program&#x2F;pooltype&#x2F;" rel="nofollow">https:&#x2F;&#x2F;shreevatsa.github.io&#x2F;tex&#x2F;program&#x2F;pooltype&#x2F;</a> and <a href="https:&#x2F;&#x2F;shreevatsa.github.io&#x2F;tex&#x2F;program&#x2F;tangle&#x2F;" rel="nofollow">https:&#x2F;&#x2F;shreevatsa.github.io&#x2F;tex&#x2F;program&#x2F;tangle&#x2F;</a>) Anyway, the example is this: see sections 53 onwards: <a href="https:&#x2F;&#x2F;shreevatsa.github.io&#x2F;tex&#x2F;program&#x2F;tangle&#x2F;tangle-6" rel="nofollow">https:&#x2F;&#x2F;shreevatsa.github.io&#x2F;tex&#x2F;program&#x2F;tangle&#x2F;tangle-6</a> — here you have a single function `id_lookup` that is hundreds of lines long and has very complex case analysis and code paths, but chopped up in a way that makes it less forbidding to understand.<p>I think though that programmers today have a strong cultural bias in favour of abstraction, so they tend to have a strong negative reaction to code like this.