I'd say Knuth is squarely in the latter category
⸻
1. https://www-cs-faculty.stanford.edu/~knuth/mmix.html
2. For people targeting a platform like JVM or CLR (dot net), understanding how those machines are implemented might also be useful, although I've found my ancient memories of 6502 and 370 assembler are sufficient for having a mental model of how the code works.
These two statements are not contradictory. We've stopped teaching CS using assembly language a long time ago, but we still do teach assembly in OS or computer architecture contexts, which is totally fine and should continue.
>Many readers are no doubt thinking, ``Why does Knuth replace MIX by another machine instead of just sticking to a high-level programming language? Hardly anybody uses assemblers these days.''
>Such people are entitled to their opinions, and they need not bother reading the machine-language parts of my books. But the reasons for machine language that I gave in the preface to Volume 1, written in the early 1960s, remain valid today:
>• One of the principal goals of my books is to show how high-level constructions are actually implemented in machines, not simply to show how they are applied. I explain coroutine linkage, tree structures, random number generation, high-precision arithmetic, radix conversion, packing of data, combinatorial searching, recursion, etc., from the ground up.
>• The programs needed in my books are generally so short that their main points can be grasped easily.
>• People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird.
>• Machine language is necessary in any case, as output of many of the software programs I describe.
>• Expressing basic methods like algorithms for sorting and searching in machine language makes it possible to carry out meaningful studies of the effects of cache and RAM size and other hardware characteristics (memory speed, pipelining, multiple issue, lookaside buffers, the size of cache blocks, etc.) when comparing different schemes.
Also, the underlying hardware he's describing isn't universal. Look at the assembly language for a vector machine (like a Cray). It's nothing like MIX.
And the fact that it's fictional it doesn't mean it won't age. Because he didn't pull the language out of thin air and he wasn't working in a vacuum, he was inspired by the trend at the time of its invention [2]. I bet if it was written today, it would look quite different, as proof of his language update for the recent editions [3]. So, it's anything but timeless, as said by even the author.
> won't age because it never existed to begin with.
Same as Da Vinci's helicopter? I think that one also aged quite poorly.
[1] https://en.wikipedia.org/wiki/MMIX
[2] https://esolangs.org/wiki/MIX_(Knuth)
[3] "In my books The Art of Computer Programming, it replaces MIX, the 1960s-style machine that formerly played such a role"
Another way of counting is that the book "The MMIX supplement", which contains the MMIX equivalents of every single page/section/program in Volumes 1–3 that is affected by the details of MIX (the book is not by Knuth but the preface indicates Knuth reviewed it very thoroughly pre-publication), is 224 pages long.
Volumes 1, 2, 3 are together 672 + 784 + 800 = 2256 pages long (and Volume 4A is 912 pages). So roughly, less than 10% of TAOCP deals with either MIX specifically, or assembly language in general.
Although I guess Volumes 1-3 haven't yet had their MIX code replaced with MMIX, so perhaps even the current ones are vintage.