4 ms·

MMIX was such a stupid idea by an otherwise genius person. So much effort and knowledge was put into TAOCP and yet it's wasted on the vast amount of people who

by pubby 9y ago

MMIX was such a stupid idea by an otherwise genius person. So much effort and knowledge was put into TAOCP and yet it's wasted on the vast amount of people who aren't interested in learning a fantasy assembly language. I can't really fault Knuth for the original MIX. I mean, it _was_ written in the 1960s; a time when programming languages barely existed. But by 2009 it should be clear to everyone that C derivatives are here to stay, and that assembly programmers are dying off. Creating yet _another_ fantasy assembly language in the year 2009 was just stubborn and dumb.

ianai 9y ago
That's like, just your opinion, man. There's always going to be that lowest level before 1s and 0s. (I say this as I'm curious if this assumption of mine is actually out of date at this point.)
- AstralStorm 9y ago
  Not really, and the hardware is getting more complex all the time. A modern CPU is like a probabilistic OS nowadays...
- wyager 9y ago
  On many modern CPUs, the assembly language that compilers use and subsequent generated machine code isn't even the lowest level representation used by the CPU. Many desktop-class processors rewrite incoming instructions into a simpler microcode instruction set more easily handled by the OOOE hardware.
brett40324 9y ago
OP contains a lengthy section titled "Why have a machine language?" Toward the end of Knuth's answer is: "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.
- wyager 9y ago
  This is dumb. There's no expressive benefit to implementing algorithms as assembly, especially imaginary assembly. "How machines actually compute" at the assembly level isn't even of interest until you need to make your algorithm go faster, at which point you need to target a real platform, not an imaginary one.
  - b0rsuk 9y ago
    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. -- from the article
    - wyager 9y ago
      Ok, cool, so use a pseudocode syntax easily understood by anyone familiar with basic control flow constructs. Most algorithms books do this, and even if they're ugly, they're certainly better than a made up assembly language.
      - defanor 9y ago
        That pseudocode is "English as the high-level language", as I understand it. Basic and common notation is used there, it's not plain English. Edit: though it's indeed not used extensively to denote control flow: that is done with "go to".
        deleted 9y ago
        [deleted]
      - b0rsuk 9y ago
pg314 9y ago
If he had used C instead of MMIX assembly language, someone would have made a very similar argument: "it's wasted on the vast number of people who aren't interested in learning a low level language like C". Or, knowing HN, somebody would have called him dumb for not using Rust... Using C, he would have run into problems by page 200 or so, where he explains how coroutines are implemented. He would have to use some assembly language there anyway. You can complain about the choices Knuth made in writing TAOCP, or you can trust him and follow one of the great masters of computing (and of writing) along an amazing journey. Calling his choices dumb or stupid without understanding the tradeoffs he made, says more about you than Knuth. I, for one, have no problem with MMIX. The description of MMIX and its assembly language is interesting in itself (he wrote an amazing simulator to accompany the book). Studying those 50 or so pages is only a tiny part of the effort required to study TAOCP (3000+ pages and growing).
svat 9y ago
How much is in machine language? You didn't say it explicitly so you may not mean it, but I see variants of this idea floating around that the assembly language is somehow a major part of the books, or that you need to learn MIX/MMIX to read the books, or even that "Knuth wrote TAOCP in assembly language". The fact is that the vast majority of content in the book (even if you consider just the algorithms/programs) is in English. As a rough measure, we can look at each volume's Appendix C—Index to Algorithms and Theorems, which lists every Algorithm, Program, Theorem, etc., and count the entries by their names: Volume 1 (Fundamental Algorithms): Algorithm 86, Coroutine 2, Law 4, Lemma 2, Program 36, Subroutine 1, Theorem 12. Total content in assembly: 36 programs (over 652 pages) Volume 2 (Seminumerical Algorithms): Algorithm 88, Corollary 5, Definition 14, Lemma 19, Program 18, Theorem 47. Total content in assembly: 18 programs (over 764 pages) Volume 3 (Sorting and Searching): Algorithm 75, Corollary 2, Lemma 8, Program 33, Subroutine 1, Theorem 41. Total content in assembly: 33 programs (over 782 pages) Volume 4A (Combinatorial Algorithms, Part 1): Algorithm 127, Corollary 12, Definition 2, Lemma 6, Program 3, Subroutine 1, Theorem 43. Total content in assembly: 3 programs (and 2 of these in Answers to Exercises) (over 883 pages). I may have made errors in counting, but the point holds: If you don't like the assembly language just ignore it; it's a tiny part of the books. Knuth uses the programs when he wants to highlight some low-level aspects. ("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.") This is not often, so most of the value of the books is got regardless of whether you read those assembly-language bits or not. And in fact, as the chapters progress towards higher-level stuff (see the TAOCP pre-fascicles Knuth has been publishing in recent years: http://www.cs.utsa.edu/~wagner/knuth/ http://www.cs.utsa.edu/~wagner/knuth/), the proportion of MMIX is even less.
torrent-of-ions 9y ago
First of all, maybe you should try learning a fantasy assembly language. It's not as hard as you seem to think. You know how driving many different cars makes you a better driver? It's the same with computers. The best programmers have programmed many different computers. A high level language forces you to see the world through its lens. Just look how differently an algorithm would be implemented in C compared to Lisp, for example. One uses a high level language because it makes things you do often much more convenient. The great benefit of C is being able to pointer arithmetic in an extremely convenient way. Lisp is more about programming in the way your brain likes to actually think, which makes it quite pleasurable. But unfortunately neither is how any computer actually works. So instead of choosing some arbitrary fashionable lens, Knuth chooses no lens, but instead invents a computer that is good for teaching, rather than being good for manufacturing and selling.
sspiff 9y ago
MMIX was published in 1999, a time when it wasn't decided that x86, and later AMD64 and ARMv7/8 would dominate all platforms. Back then, Alpha had only recently been killed, and things Itanium were coming up, Apple sold PowerPC computers and Windows devices running ARM, MIPS and SuperH were being widely sold. In the spirit of 1999, a fantasy architecture was not a bad way to gloss over that fragmentation. Also, x86 is not an elegant teaching platform (though I hear AMD64 is much better).
mhh__ 9y ago
Come on, it's not exactly difficult to read? If Knuth used loads of rare x64 instructions then I'd accept the premise, but this is(http://mmix.cs.hm.edu/doc/instructions-en.html http://mmix.cs.hm.edu/doc/instructions-en.html) is practically simple.
sethrin 9y ago
Thank you for provoking a vigorous debate on this subject. It's clear that many people disagree with you, which hopefully should not be a good reason for downvoting. I had mentioned two days ago at a meetup that I had been intending to make a serious attempt at Knuth in the near future, and the person to which I made that remark vociferously asserted the uselessness of Knuth for that very reason. I was completely unprepared to reply, and the discussion here is proving extremely useful. The overall tone of your comment was probably a mistake unless you were being deliberately provocative to take advantage of Cunningham's Law.

by pubby 9y ago

ianai 9y ago

That's like, just your opinion, man. There's always going to be that lowest level before 1s and 0s. (I say this as I'm curious if this assumption of mine is actually out of date at this point.)

AstralStorm 9y ago
Not really, and the hardware is getting more complex all the time. A modern CPU is like a probabilistic OS nowadays...
wyager 9y ago
On many modern CPUs, the assembly language that compilers use and subsequent generated machine code isn't even the lowest level representation used by the CPU. Many desktop-class processors rewrite incoming instructions into a simpler microcode instruction set more easily handled by the OOOE hardware.

brett40324 9y ago

OP contains a lengthy section titled "Why have a machine language?" Toward the end of Knuth's answer is: "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.

wyager 9y ago
This is dumb. There's no expressive benefit to implementing algorithms as assembly, especially imaginary assembly. "How machines actually compute" at the assembly level isn't even of interest until you need to make your algorithm go faster, at which point you need to target a real platform, not an imaginary one.
- b0rsuk 9y ago
  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. -- from the article
  - wyager 9y ago
    Ok, cool, so use a pseudocode syntax easily understood by anyone familiar with basic control flow constructs. Most algorithms books do this, and even if they're ugly, they're certainly better than a made up assembly language.
    - defanor 9y ago
      That pseudocode is "English as the high-level language", as I understand it. Basic and common notation is used there, it's not plain English. Edit: though it's indeed not used extensively to denote control flow: that is done with "go to".
      - deleted 9y ago
        [deleted]
    - b0rsuk 9y ago

pg314 9y ago

If he had used C instead of MMIX assembly language, someone would have made a very similar argument: "it's wasted on the vast number of people who aren't interested in learning a low level language like C". Or, knowing HN, somebody would have called him dumb for not using Rust... Using C, he would have run into problems by page 200 or so, where he explains how coroutines are implemented. He would have to use some assembly language there anyway. You can complain about the choices Knuth made in writing TAOCP, or you can trust him and follow one of the great masters of computing (and of writing) along an amazing journey. Calling his choices dumb or stupid without understanding the tradeoffs he made, says more about you than Knuth. I, for one, have no problem with MMIX. The description of MMIX and its assembly language is interesting in itself (he wrote an amazing simulator to accompany the book). Studying those 50 or so pages is only a tiny part of the effort required to study TAOCP (3000+ pages and growing).

svat 9y ago

How much is in machine language? You didn't say it explicitly so you may not mean it, but I see variants of this idea floating around that the assembly language is somehow a major part of the books, or that you need to learn MIX/MMIX to read the books, or even that "Knuth wrote TAOCP in assembly language". The fact is that the vast majority of content in the book (even if you consider just the algorithms/programs) is in English. As a rough measure, we can look at each volume's Appendix C—Index to Algorithms and Theorems, which lists every Algorithm, Program, Theorem, etc., and count the entries by their names: Volume 1 (Fundamental Algorithms): Algorithm 86, Coroutine 2, Law 4, Lemma 2, Program 36, Subroutine 1, Theorem 12. Total content in assembly: 36 programs (over 652 pages) Volume 2 (Seminumerical Algorithms): Algorithm 88, Corollary 5, Definition 14, Lemma 19, Program 18, Theorem 47. Total content in assembly: 18 programs (over 764 pages) Volume 3 (Sorting and Searching): Algorithm 75, Corollary 2, Lemma 8, Program 33, Subroutine 1, Theorem 41. Total content in assembly: 33 programs (over 782 pages) Volume 4A (Combinatorial Algorithms, Part 1): Algorithm 127, Corollary 12, Definition 2, Lemma 6, Program 3, Subroutine 1, Theorem 43. Total content in assembly: 3 programs (and 2 of these in Answers to Exercises) (over 883 pages). I may have made errors in counting, but the point holds: If you don't like the assembly language just ignore it; it's a tiny part of the books. Knuth uses the programs when he wants to highlight some low-level aspects. ("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.") This is not often, so most of the value of the books is got regardless of whether you read those assembly-language bits or not. And in fact, as the chapters progress towards higher-level stuff (see the TAOCP pre-fascicles Knuth has been publishing in recent years: http://www.cs.utsa.edu/~wagner/knuth/ http://www.cs.utsa.edu/~wagner/knuth/), the proportion of MMIX is even less.

torrent-of-ions 9y ago

First of all, maybe you should try learning a fantasy assembly language. It's not as hard as you seem to think. You know how driving many different cars makes you a better driver? It's the same with computers. The best programmers have programmed many different computers. A high level language forces you to see the world through its lens. Just look how differently an algorithm would be implemented in C compared to Lisp, for example. One uses a high level language because it makes things you do often much more convenient. The great benefit of C is being able to pointer arithmetic in an extremely convenient way. Lisp is more about programming in the way your brain likes to actually think, which makes it quite pleasurable. But unfortunately neither is how any computer actually works. So instead of choosing some arbitrary fashionable lens, Knuth chooses no lens, but instead invents a computer that is good for teaching, rather than being good for manufacturing and selling.

sspiff 9y ago

MMIX was published in 1999, a time when it wasn't decided that x86, and later AMD64 and ARMv7/8 would dominate all platforms. Back then, Alpha had only recently been killed, and things Itanium were coming up, Apple sold PowerPC computers and Windows devices running ARM, MIPS and SuperH were being widely sold. In the spirit of 1999, a fantasy architecture was not a bad way to gloss over that fragmentation. Also, x86 is not an elegant teaching platform (though I hear AMD64 is much better).

mhh__ 9y ago

Come on, it's not exactly difficult to read? If Knuth used loads of rare x64 instructions then I'd accept the premise, but this is(http://mmix.cs.hm.edu/doc/instructions-en.html http://mmix.cs.hm.edu/doc/instructions-en.html) is practically simple.

sethrin 9y ago

Thank you for provoking a vigorous debate on this subject. It's clear that many people disagree with you, which hopefully should not be a good reason for downvoting. I had mentioned two days ago at a meetup that I had been intending to make a serious attempt at Knuth in the near future, and the person to which I made that remark vociferously asserted the uselessness of Knuth for that very reason. I was completely unprepared to reply, and the discussion here is proving extremely useful. The overall tone of your comment was probably a mistake unless you were being deliberately provocative to take advantage of Cunningham's Law.