[tomcart]

There is surely a distinction between vintage and timeless, where the first is representative of the time it was written (and may offer relevant insight for today), and the second offers some universal truth, regardless of when it was written.

I'd say Knuth is squarely in the latter category

[decebalus1]

I'm gonna have to go against the grain here and completely disagree with this. While TAOCP is lauded and celebrated as one of the best (and at the same time unread) CS books of all time, the fact that it uses an assembly language is a strong indicator that it's 'vintage'. It still has that 'universal truth' but at the same time, as you said 'is representative of the time it was written', considering MIX is picked for teaching people how to program.

[svat]

Note that only a very small part of the TAOCP books is in assembly language. My count from a few years ago: https://news.ycombinator.com/item?id=14520230

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.

[dhosek]

The newer volumes use a newer version of MIX, MMIX¹ based on RISC architecture, which will also appear in the "ultimate" revisions of Vols I–III. And while you might think that assembly language is ipso facto an indicator of vintage, I think having at least one assembly language² in one's experience is helpful for having some idea of what the computer is actually doing.

⸻

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.

[dhosek]

I also should provide DEK's own reasoning about why assembly and not a higher-level language:

>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.

[criddell]

At the same time, his programs do things like modify themselves. CPUs and operating systems haven't let you do stuff like that for a while now, at least not without disabling system protections.

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.

[dhosek]

If you look at the link, Knuth does talk about how self-modification is an obsolete practice and something he has been removing.

[decebalus1]

> And while you might think that assembly language is ipso facto an indicator of vintage, I think having at least one assembly language² in one's experience is helpful for having some idea of what the computer is actually doing.

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.

[bombcar]

It's precisely because it uses a "fake" assembly language that it can continue to be timeless; the books written using FORTRAN are now historical artifacts, and perhaps only C would really survive that long; and C is basically glorified assembly language anyway ...

[exdsq]

I'd say the reasons you say it's vintage are the exact reasons I'd say it's timeless! It's a fictional assembly language which is at the level of abstraction he wants and something that won't age because it never existed to begin with.

[decebalus1]

No, it's not timeless. Only the fact that it was updated to MMIX [1] proves that it's not.

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"