"I think of him as sort of a godfather," says software engineer Ellen Ullman, author of "Close to the Machine: Technophilia and its Discontents." "It would be very difficult these days to take a job and approach programming in that sort of algorithm and design sense, [but] it's a solace to think that there are places where people think deeply about algorithms in a general and abstract way and have notions of elegance and beauty."

Of course, other computer scientists have made contributions to the field that are every bit as substantial (most notably Edsger Dijkstra, Tony Hoare and Niklaus Wirth). But Knuth's work brings to life the complex mathematical underpinnings of the discipline, and deals with the logistics of programming on all levels, from the conceptual design of solutions to the most intimate details of the machine. The fundamental elements of any computer program are, perhaps not surprisingly, time and space. (In programming terms, time describes the speed with which a program accomplishes its task, while space refers to the amount of memory a program requires both to store itself -- i.e. the length of the code -- and to compute and store its results.) But Knuth is concerned not only with bytes and microseconds, but with a concept that has come to be known in coding circles as "elegance," and that applies to programming at any level.

Elegance takes in such factors as readability, modular coding techniques and the ease with which a program can be adapted to other functions or expanded to perform additional tasks. (Knuth's broader ideas about documentation and structured programming are laid out in his 1992 book, "Literate Programming.") Though rarely mentioned, "sloppy coding" often costs companies a great deal in terms of time and money; programmers brought in to update the code of consultants gone by must spend hours or days deciphering a poorly documented program, or hunting down bugs that might have been caught easily had the initial programmer simply been a bit more conscientious in the practice of his craft.

Ullman points out that "the practice of programming has moved very far away from the notion that the professional programmer considers algorithms in a deep way. Of course," she adds, "it would be impossible if every bit of code had to go through that kind of deeply professional process. On the other hand, the code that we have would be better. There's no doubt in my mind that it would be better and more long-lasting code."

Ullman, however, admits she hasn't revisited Knuth's work in many years. Many people are put off on even a first reading by the "mythical" computer with which Knuth illustrates his concepts. MIX, "the world's first polyunsaturated computer," was designed by Knuth as a kind of ideal machine along the lines popular in the 1960s. (Knuth is now updating MIX to MMIX, a reduced instruction-set computing machine that more closely mimics computers in use today.) "The Art of Computer Programming" is filled with examples in MIX, Knuth's fictional machine code and assembly language. In today's world of natural-language compilers, pseudo-code and "click-and-drag" programming tools, though, learning a new assembly language is as attractive to most students of computer science as a visit to the dentist.

But programmers ignore "the very pulse of the machine" (a Wordsworth quotation found in Volume 1) at their peril. As Lyle Ramshaw, a former graduate student of Knuth's, points out, "Don claims that one of the skills that you need to be a computer scientist is the ability to work with multiple levels of abstraction simultaneously. When you're working at one level, you try and ignore the details of what's happening at the lower levels. But when you're debugging a computer program and you get some mysterious error message, it could be a failure in any of the levels below you, so you can't afford to be too compartmentalized."

"MIX was incredibly popular in the early '70s," Knuth says. "Right now there are a lot of comments on Amazon.com saying how it was my terrible mistake, and how am I ever going to recover from it? Well, some of those comments are right, but some of them are dead wrong. The people who say I shouldn't have machine language and just go into high-level languages, they're the ones I think are wrong."

In fact, without machine code, it would be impossible for Knuth to even attempt the low-level analyses (like the time spent executing each instruction in a computer program) that are the backbone of his work. The same BASIC program, for instance, may run at different speeds and use different amounts of memory on different types of machine. In addition, such languages tend to go in and out of vogue faster than a Madonna single. If Knuth based his books on Java, C++, VisualBASIC or SNOBOL (remember SNOBOL?), they'd be obsolete in a matter of months.

And as Knuth points out, "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."

The Free Software Project
Read Andrew Leonard's book-in-progress on Linux and open source -- and post your comments.