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?
Most programmers are lazy. I know I am. I know the other (senior) coder on our current project is. But it's a controlled laziness.
Being lazy means that instead of doing something "manually" we'll find some way to make the computer do it for us. Sure, doing it by hand may only take 5 minutes and we'll spend 15 minutes just trying to convince the computer to do it, but that's not the point. The point is that - 1) you just learned something new, 2) you avoided doing a repetitive task repeatedly (yes, yes, I know), 3) odds are you'll do the same damn thing, or something similar in the future, and then you'll know how to do it in 3 seconds.
Which is why programmers gravitate to complex but programmable tools, like vi/vim/emacs/ultraedit, to Unix, to scripting languages, etc.
It's also why we don't understand the user more often then not. Most users just want to get the job done. Sure, there may be a more efficient way to do it if you spend some time learning the system, but they either don't view the system as their job or have been burned by it too many times to trust it. So they do things the way they know, or the way they think it should work. Which is often not the way the lazy programmer thinks.
Laziness does have downsides though. Documentation tends to be banal. Comments are almost never as good as you'd like them to be 3 months later. And while algorithmic simplicity is a noble goal, it's often the wrong one - too simple of an algorithm can be wasteful of resources (bubble sort is a whole lot simpler than quicksort) simply because the programmer didn't learn the underlying hardware or didn't think through the implications of a design. Which leads to the issue of too simple of a design meaning massive rework as the system grows.
Of course the more experienced programmers have learned these things and discovered that spending the time up front means you can be lazier in the long run.
Knuth is one of these experienced programmers. There are gems of wisdom throughout his writings.
Wish the bastard didn't want us to work to find them though.
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.
256 pennies would be 100 hex cents, not 100 hex dollars.
;-)
Not quite. 256 *anything* equals $100. Several symbolic assemblers represent hexadecimals with a $ prefix. This has nothing to do with money. Claiming that the number is in fact a fixed point decimal representation is just semantics, not visible in the assembly code.
Just to make it completely clear.
"I have opinions of my own, strong opinions, but I don't always agree with them." -- George H. W. Bush
It's really a shame to read all these comments from people who have never heard of The Art of Computer Programming... Shows the average intellectual level of slashdot readers. To make things worse, some of the individuals are proud to not know Knuth or to state that his books are useless or boring.
Shame...
I would suggest rather getting ghostscript for Windows, the free PostScript interpreter, and also GSview, a viewer (the latter requires the former).
Ghostscript is free as in speech, with a GNU release and a release under AFPL, a slightly different license (the GNU code is older than the AFPL code). GSview is available, as far as I can tell, under the AFPL only, which is still free but not GPL.
With both of these properly installed on Windows, one click on the link provided by Slashdot will launch the viewer. (It must gunzip on-the-fly.)
"Never bullshit a bullshitter" All That Jazz
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
If you'd been around when TeX came out, you wouldn't be saying that. If you were serious about preparing math-heavy documents, you wouldn't be saying that.
What do you consider a good system now -- docbook? If so, remember that your docbook renderer uses TeX as its backend. If you consider (say) Word a good document preparation system, you have no room to speak on the subject.
TeX is an amazingly reliable, high-quality piece of software -- I doubt that anything on its scale has ever been created with as few bugs. Yes, the input syntax is a bit dated -- but in its day, it kicked ass. No doubt if Knuth were doing it today, it'd kick ass by modern standards as well.
And there is a good reason that his opinion is worth much more than yours ;)
All of his justifications for using MIX are valid today. He is moving to MMIX, which is a good model for modern processors (recall that when he started this, MIX was a pretty good model for existing processors).
The main points for why MIX/MMIX are a good choice?
-there are is no language wierdness between you and the algorithims, not even the quirks of a particual assembly set.
-every fully competent coder must have done a bit of assembly (I guess there could be exceptions to this, but I have never met one... and I have worked with a lot of coders). This is as good a place as any to get that experience if you don't have it. Actually, it is probably better than learning a strange assembly.
-any competent coder can translate on the fly from the MIX/MMIX algorithms to their language of choice. This would be much less true if Knuth had used a language-of-the-year.
S.