I don't hate using assembly language, since I have written some in my os course. But obviously, assembly language lacks abstraction, you have to pay more attention to the details.
Is assembly language really essential to write TAOCP?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this communityI don't hate using assembly language, since I have written some in my os course. But obviously, assembly language lacks abstraction, you have to pay more attention to the details.
Is assembly language really essential to write TAOCP?
He not only uses MIXAL, his assembly language for MIX, but also MIX, a model for a simple computer (like one which was used in the sixties). This is a model for teaching with which he is, to some extent, independent of development in the field.
If he'd used another programming language (which one, by the way, would you think would have been suited?), say NPL (nifty programming language), he would have had to either abandon the idea of using MIX or to introduce a compiler of some computer language of choice (which is a far more complex thing than what he is dealing with in Vol 1). That way it would not have become TAOCP but TAONPLP. The first one is independent of such a choice and, for this reason, timeless in a way few books about programming will ever be. The second one would probably be forgotten by now...
Also, as long as computers are working in principle the way his MIX does, it is a good thing to take that into account if you are really interested in learning how to work with them.
You young whippersnappers amaze me sometimes. You all too often have no clue that anything happened before you started school. (I have the same problem. It took me a long time to grasp that 15 years was actually a very short time, from an adult viewpoint. That's roughly the span from Hiroshima to the Cuban Missile Crisis. To me, World War II is just history, but my father fought in it, and my mother was in junior high during it.)
TAOCP, vol. 1, "Fundamental Algorithms", 1st edition, was first printed in 1968. That's 45 years ago. Knuth started planning the series well before then.
For reference: The Intel 8086 first appeared in 1978, ten years later. The PASCAL language first appeared in 1971; the Jensen & Wirth book, about the second version of the language, came out in 1974. Initial development of C was 1969-1973: K&R was published in 1978.
Knuth intended the series to cover the field. He set the style, THEN, to be useful to practitioners THEN. He did not ever expect that series to become quite literally his life's work, or its writing to span what will probably be well over half a century when he finally finishes.
Assembly language is arguably not as critical today as it was then, but it is still far more important than the Java/C++/Javascript/Python/Perl mavens would like you all to believe.
Now GET OFF MY LAWN!
Knuth discusses his reasoning in the Preface. I'll quote just a few bits and pieces:
...I needed to decide whether to use an algebraic language such as ALGOL or FORTRAN, or to use a machine-oriented language for this purpose. Perhaps many of today's computer experts will disagree with my decision to use a machine-oriented language, but I have become convinced that it was definitely the correct choice, for the following reasons:
- Algebraic languages are more suited to numerical problems than the nonnumerical problems considered here. [ ... ]
- ...By writing in a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality.
- The programs we require are, with few exceptions, all rather short...
- A person who is more than casually interested in computers should be well schooled in machine language...
- Some machine language would be necessary anyway...
Although he doesn't point it out directly, I think his mention of ALGOL and FORTRAN points to another problem he avoided that may be even more important. Let's assume he had chosen Algol (clearly better suited to non-numeric programs than Fortran anyway). I would posit that Algol would probably be even more foreign to most of today's programmers than the assembly language he chose.
For the third edition, he redesigned the MIX to fit more closely with modern processors, and had to rewrite the code for it. I'd posit, however, that had he used a higher level language, the rewrite would have been substantially greater -- and all the reasons he gave would remain as well.
Knuth has updated his rationale as well:
Why have a machine 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.
Moreover, if I did use a high-level language, what language should it be? In the 1960s I would probably have chosen Algol W; in the 1970s, I would then have had to rewrite my books using Pascal; in the 1980s, I would surely have changed everything to C; in the 1990s, I would have had to switch to C++ and then probably to Java. In the 2000s, yet another language will no doubt be de rigueur. I cannot afford the time to rewrite my books as languages go in and out of fashion; languages aren't the point of my books, the point is rather what you can do in your favorite language. My books focus on timeless truths.
Therefore I will continue to use English as the high-level language in TAOCP, and I will continue to use a low-level language to indicate how machines actually compute. Readers who only want to see algorithms that are already packaged in a plug-in way, using a trendy language, should buy other people's books.
The good news is that programming for RISC machines is pleasant and simple, when the RISC machine has a nice clean design. So I need not dwell on arcane, fiddly little details that distract from the main points. In this respect MMIX will be significantly better than MIX.