Slashdot Mirror
Knuth Releases Another Part of Volume 4
junge_m writes "Donald Knuth has released another of his by now famous pre-fascicles to Volume 4 of his epic:
Pre-fascicle 2c is all about 'Generating all Combinations' supplementing his pre-fascicles 2a and 2b.
Furthermore he challenges us all to do more of his daunting exercises and report our success. He thinks we are way too lazy in this respect! So come on slashdot crowd: Do your homework and get the credit from the grandmaster himself!"
Knuth's own reply to this question can be seen at http://www-cs-faculty.stanford.edu/~knuth/mmix.htm l.
To quote:
"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. "
~~~~~ BigLig2? You mean there's another one of me?
He is beyond hardcore. To explain Donald Knuth's relevance to computing (and geeks should all know who he is) is like explaining Paul's relevance to the Catholic Church. He isn't God, he isn't the Son of God, but he was sent by God to explain God to the masses.
Reading the Art of Computer Programing is like translating the Bible from the original greek. You know there is something profound there, but until you've done it a few times and looked back on it, you are more concerned with trying to figure out each word.
I'm a little awestruck by him.
By the way, the Paul reference is not a flippant one, check out his other books,Things a Computer Scientist Rarely Talks About , and 3: 16: Bible Texts Illuminated, for explanations of why not every christian is a fool.
Never confuse volume with power.
Too too many programmers think a line of code is a line of code. They think strcat is just hunky-dory, and append great gobs of strings this way, without realizing that each append traverses the entire string from the beginning each time. They use malloc and free, new and delete, with abandon, not realizing how much they are thrashing the malloc heap, when local variables on the stack would do just as well 99% of the time.
They DO NOT UNDERSTAND the concept of finite resources, that machine cycles cost time.
I believe the first programming course should be a very few weeks of something akin to LOGO, or BASIC, just to get the concept of bugs and such out of the way, weed out those who can't stand thinking. Then a good grounding in a z80 or some other simple 8 bitter, where counting cycles and bytes is part of the course (learn how expensive those cute index registers really are). Only then, when an understanding of machine cycles and bytes has been established, should students move on to a higher level.
Too many ivory towers out there, too many straight-A-can't-tie-their-shoelaces types.
Infuriate left and right