Donald Ervin Knuth is trying to explain what has delayed work on Volume 4 of his magnum opus. “I’ve never been a good estimator of how long things are going to take,” he says.

Coming from someone who’s been writing one book on and off for the past quarter-century, this seems a bit of an understatement. But when you consider that most of Knuth’s work has been devoted to just that — figuring out how much time things like computer programs take — and the statement takes on new (and slightly disingenuous) meanings.

“I’m getting toward being able to take up Volume 4 full time,” Knuth says. “I’m writing little snippets. I wrote a sentence just the other day.”

“Volume 4,” of course, refers to the long-awaited next installment of Knuth’s masterwork, “The Art of Computer Programming.” Less a set of instruction manuals than a kind of analytic philosophy of programming, the books — which first appeared in the 1960s — lay out principles both broad and specific to guide computer programmers toward greater efficiency. So comprehensive are the texts that the Jargon File of hacker slang offers a definition of the word “Knuth”: “Mythically, the reference that answers all questions about data structures or algorithms,” and goes on to recommend a safe response to any question for which you don’t have a ready answer: “I think you can find that in Knuth.”

Time was when such a comment would have the curious programmer dusting off “Fundamental Algorithms” and “Sorting and Searching” (Volumes 1 and 3 of “Knuth”), which were required reading in computer science courses for decades. But modern keyboard jocks no longer worry about things like saving 11 microseconds in each iteration of a binary tree search (if they even know what a binary tree is). Instead, they spend their time assembling prefab software components and designing graphical user interfaces to wow clients. Some “write” whole systems having never even seen a line of code. To them, Knuth, now professor emeritus of the art of computer programming at Stanford University, is irrelevant, abstruse and bothersome because he illustrates concepts in machine code, the lowest-level programming language and the hardest to read.

If his attention to the minutiae of programming has earned the annoyance of a younger generation of programmers, though, Knuth remains the iminence grise of algorithm analysis, and one of the leading thinkers on programming in general.

“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.”