I've read the books, and would recommend that others interested in Computer Science (and not just software engineering) do too.

But let's get a few misconceptions out of the way.

First: TAOCP is not an algorithm textbook. People who say "CLRS (or Sedgwick) is better" are missing the point. If you want an Algorithm textbook/cookbook, there are lots of good ones to choose from. TAOCP shouldn't be on that list.

Second: The algorithms listed are not implemented in MMIX. The vast majority are written in English. Knuth uses MMIX to show implementation details only on a small subset of algorithms where it is relevant to the functioning of the algorithm (for example, in 7.1.3), or where it is instructive to learning about how computers actually behave (for example, in 1.3.1').

Third: The books shouldn't be read in order, cover to cover. Knuth specifically warns that Chapter 1 provides the mathematical basis for the later chapters, and should be quickly skimmed and returned to as needed.

Fourth: The books aren't "dry" or boring. There's a lot of humor there, much of it hidden in odd places (like the index, or the exercises.) Knuth is a funny guy (his first publication was in Mad Magazine, for chrissakes) and his personality shines through.

I'd recommend that new readers begin with Volume 4 Fascicle 0, which gives a good taste of what the series is about. Read the text, quickly first, and then slowly, and try your hand at a few of the exercises.

You won't be sorry.

Knuth is alleged to have described them as "the most purchased, least read" computer science books.[*]

[*] in the interests of historical accuracy I have sent him a note asking him to clarify. I'll follow up with any response.

Update: Knuth has responded, and this story is False.

His response is here:

http://stackoverflow.com/questions/3126096/did-knuth-ever-refer-to-taocp-as-the-most-purchased-least-read-computer-scienc

Update: response deleted. Permanent home now here:

http://markharrison.net/stackoverflow/knuth/
which in turn points here:
http://codehaus.blogspot.com/2012/03/note-from-donald-knuth-about-taocp.html

Before I answer this question let me quote Joel Spolsky:

"[Programmers] who started programming by copying JavaScript snippets [...] and went on to learn Visual Basic never learned about pointers, and they can never quite produce code of the quality you need."

I agree with him: even if you spend your entire life writing Java or any other language in which you never have to worry about pointers, you'll never be as good a programmer as if you were aware of what's going on behind the scenes. I firmly believe that universities should teach C and not Java for this reason. And the same holds true with respect to fundamental algorithms.

That's why I still think any programmer that's serious about their work should at least skim through Knuth's work. Or can you tell me what are the specific situations where qsort performs worse than any other algorithm? Or how to randomly sample n test datapoints out of a pool of m points? Or how to test the quality of your random number generator?

I have the first three volumes on the shelf along with a slowly building collection of the fascicles as well. However, like many others I really haven't opened them up and read them cover to cover, most of the time I just use them to look-up a particular topic that I am working on.

As a reference I have found the Fundamental Algorithms and Sorting and Searching books to be of great use and the fascicles to be useful on some specific problems I have been working on.

I have also heard the arguments that they tend to be too low level for most people to find them useful, but I tend to disagree. While the examples in MMIX assembly (FYI - MMIX has not been implemented in hardware ^[1]) tend to be of dubious use at times and I would like to see some C like examples, I have come to notice that if I can understand the concept being explained and the associated MMIX code, I can generally implement it in the language of my choice.

This is a very common misconception. TAOCP is not to be read, but studied. Quoting Alexander Stepanov:

"How does one learn to recognize general components? The only reasonable approach is that one has to know a lot of different general- purpose algorithms and data structures in order to recognize new ones. The best source for finding them is still the great work of Don Knuth, The Art of Computer Programming. It is not an easy book to read; it contains a lot of information and you have to use sequential access to look for it; there are algorithms that you really do not need to know; it is not really useful as a reference book. But it is a treasure trove of programming techniques. (The most exciting things are often to be found in the solutions to the exercises.) I have been reading it for over 30 years now and at any given point I know 25% of the material in it. It is, however, an ever-changing 25% – it is quite clear now that I will never move beyond the one-quarter mark. If you do not have it, buy it. If you have it, start reading it. And as long as you are a programmer, do not stop reading it! One of the essential things for any field is to have a canon: a set of works that one must know. We need to have such a canon and Knuth’s work is the only one that is clearly a part of such canon for programming."

Read all three. They were obsolete (by the computer language standard) even then. Still, a colleague and I wrote a working MIX interpreter in the Pascal language (Turbo Pascal, I believe).

That was aeons ago - about 15 years, I believe. I can't remember any more what I learned from them, but still, I do remember that they gave me a great reading pleasure. Maybe I'll have to reread them.

Books are important.

I have the three volumes on my bookshelf. Every once in a while, when I'm thinking about an algorithm, I'll look it up and skim through what Knuth has written. I've always wanted to try a thorough study, but just can't find the time.

I should note that about half of the books on my bookshelf are unread. Knuth isn't special in that regard.

These books are treasures. Today, many of the programming languages have so many high level functions, it is easy to dismiss the "best" algorithm since its easier to use the built in function. I know that understanding sorting on multiple tape drives is pretty archaic in today's world, but, if you don't understand the underlying principles and some of the math (and there's a lot in Knuth's work) there's still a lot to discover in these books. Those that dismiss these as elitist or "too basic" might consider a career in marketing or sales.

(I would put this as a comment to the post that posed the question, but I do not have a sufficiently high rating to do so, so I am putting the answer here for now.)

Vulcan Eager's answer of Aug 24 at 10:55 asks:

Question 1: "Furthermore f should leave omega pointwise fixed; that is, f(q) should equal > q for all elements q of omega."

Why?

The remainder of that paragraph also says that "The computational sequence is said to /terminate in k steps/ if k is the smallest integer for which x_k is in Omega ..." This additional note, combined with some thought about what the four pieces of the quadruple (Q,I,Omega,f) represent, leads to an answer:

The Omega component is the set of final states of the computation (that is, the ones where there is no further computation to be done).

If you think of the function f as being invoked on every clock tick, then f will still be invokes as time passes, but you do not want a final machine state to change in response to such ticks; therefore to properly model final states, you need f to leave Omega pointwise fixed.

Throughout the volumes of TAOCP, insights like this are not spelled out, but rather left for the reader to see on their own. This makes reading TAOCP difficult, but also quite rewarding, since it is filled with such "Aha!" moments for the reader who is willing to work for them.

I read volume one almost 20 years ago. All the examples use Knuth's own MIX assembly language which made it heavy going. What sticks in my mind is the revelation that bytes don't have to be 8 bits.

I read all three. But I have to say, I couldn't wrap my head around all the math. Then I started to learn more about the math involved. So maybe the books have a good influence.

Yes. I have read both volumes I and III. Volume II, with its focus on random number generation was too much, and I didn't make it through. The MIX was alright, though I had to spend a bit of time in volume I making sure I understood all of it.

It was kind of underwhelming actually:

• Book 1 had some very basic data structures stuff. This stuff can be found in any reasonably modern book.

• As a CS Theory student (algorithms & complexity), book 3 was mostly pointless and dealt with two very limited and narrow algorithmic problems which aren't terribly interesting from an algorithmic perspective. However, I did learn how to write a correct binary search -- it's harder than it looks with all the off by 1 errors!

My general opinion is that these are monolithic works of historical importance, but practically (or even theoretically!), your time could be better spent reading other things.

On the other hand, I have great respect for Knuth's other math/CS Theory works, and I've found those really enlightening. I'm looking forward to Volume 4B (Graphs and Networks) of TAOCP.

I managed to bag myself the collection at a cut down price on Amazon a few weeks ago. I have it here on my desk and fully intend to eventually get through all three volumes.

Reality may not meet my intentions but it was a set that I have always wanted for my programming bookshelf.

Have the first three volumes and they make for great elitist decoration! I've probably spent all of 3-4 hours poking through the volumes, mostly just to read snippets of when I am bored and feel like some math.

Word has it they are great books and highly educational if you willing to put time in them.

I just got myself the first volume. I certainly intend to read it cover-to-cover. Need some help at the end of section 1.1. The math used to describe a computational method is confusing me. It does look like set theory but I could do with some pointers here.

Question 1: "Furthermore f should leave omega pointwise fixed; that is, f(q) should equal q for all elements q of omega."

Why?

I'm waiting for Knuth to finish all the volumes and then purchase a nice boxed set...

(I am always pissed off when I get the DVD of a film I liked and then a it becomes a trilogy, I get the other two DVD's and a few months later I see in the store all the DVD's in a nice pack, with extras and cheaper than the ones that I bought separately).

I also haven't read it. I think it's on too low level (examples in assembly, lots of math). For me Introduction to algorithms ^[1] is more suitable book.

Yeah, I also think that most people who claim owning TAOCP probably never read it.. maybe just short snippets to see how it looks like..

These books are on my to read stack...but I haven't gotten to them yet.

Any self respecting computer "expert" needs to own them to be a part of the "real" computer science culture. Although, reading them cover to cover is another story. ;-)

I have tried to read them and they are just too low-level and dry to enjoy reading them through. That is, they are not fun to read. However, they are great reference books and if there is an algorithm you want to understand and implement from scratch, they are a great place to start, if not a one stop destination.

I got a professors copy of the first book free for answering some mathematical question right when I joined university. I've skimmed through it and found lots of interesting stuff, but too much reading it and my eyes really do start to glaze. I like them better as reference books than as cover to cover must reads.

Prob the most inaccurate title of all time... if any books should be called "The Science Of Computer Programming” then these are those!

I have them, and have never read them. I do declare myself to be a sucky programmer though, so no big loss.

Own them, started reading volume one a couple times, never made it past page 27.

no, reason for this: My school didn't encourage me to do this (however at least we read some other interesting books..) and simply the lack of time. I hope that I'll find time at some point to read it..

We have done many excercises from those books during my University course (during seventies!) and till now, when I want to check specific algorithm and see ups and downs of it, I still look ito it.

However reading them from cover to cover unfortunately seems to me close to impossible.

Havent' read the book, catchy title though.