Ask Slashdot: Have You Read 'The Art of Computer Programming'? (wikipedia.org)

In 1962, 24-year-old Donald Knuth began writing The Art of Computer Programming, publishing three volumes by 1973, with volume 4 arriving in 2005. (Volume 4A appeared in 2011, with new paperback fascicles planned for every two years, and fascicle 6, "Satisfiability," arriving last December). "You should definitely send me a resume if you can read the whole thing," Bill Gates once said, in a column where he described working through the book. "If somebody is so brash that they think they know everything, Knuth will help them understand that the world is deep and complicated."

But now long-time Slashdot reader Qbertino has a question: I've had The Art of Computer Programming on my book-buying list for just about two decades now and I'm still torn...about actually getting it. I sometimes believe I would mutate into some programming demi-god if I actually worked through this beast, but maybe I'm just fooling myself...

Have any of you worked through or with TAOCP or are you perhaps working through it? And is it worthwhile? I mean not just for bragging rights. And how long can it reasonably take? A few years?
Share your answers and experiences in the comments. Have you read The Art of Computer Programming?

Comments

Unfortunately no and I have a reason

[Anonymous Coward]

Unfortunately no and I have a reason:
Reading those books requires high degree of mathematical sophistication, particularly, knowledge of complex analysis, which I lack.

Re:Unfortunately no and I have a reason

[lgw]

Reading those books requires high degree of mathematical sophistication, particularly, knowledge of complex analysis, which I lack.

They're just algorithms textbooks. They're hard to read because of when they were written, and the accompanying style. More like pseudo-assembly than high-level pseudo-code.

But, hey, if you want to optimize your search algorithm that uses tape as storage, to take advantage of the new-fangled tape drives that can write backwards as well as forwards, it's the book for you! (Yes, that was really a thing, and an algorithm you'll find in Volume 3: Sorting and Searching.)

Personally, I don't think he does a great job explaining algorithms. I once needed to look up O(n) median for something, tried to understand it from Knuth, gave up on the cryptic text, and understood it right away from CLR (now CLRS). It is an exhaustive catalog, but it's not a great learning tool.

Re:Unfortunately no and I have a reason

[ShanghaiBill]

Personally, I don't think he does a great job explaining algorithms .... It is an exhaustive catalog, but it's not a great learning tool.

I agree with all of the above. There are better books. But criticizing TAOCP is like saying the emperor has no clothes. The series is difficult to understand, and everyone thinks it is their own fault for not being smart enough, rather than that the books actually aren't very good.

Disclaimer: I own the entire series, and keep them in my office to impress people, but I haven't actually opened them in the last 20 years.
Additional Disclaimer: I loved Don's "Concrete Mathematics" book ... for the humor as well as the math. I keep it in my office to impress people too.

Re:Unfortunately no and I have a reason

[bzipitidoo]

CLR is Introduction to Algorithms by Cormen, Leiserson and Rivest. The S in CLRS is for Stein, who joined the team for the 2nd edition. When CLR came out in 1990, it was hailed as the best algorithms textbook ever, and what an algorithms textbook should be, a huge jump in readability and clarity over the not wholly satisfying existing algorithms textbooks. It uses pseudocode, instead of a real programming language. Allowed the algorithms to be presented cleanly, without any boilerplate code, overhead, or worries about limitations, no need for tedious checks for array out of bounds, numeric overflow, or out of memory, or invalid input. Don't have to declare any variables, or figure out how many elements an array needs.

The Abelson and Sussman textbook, Structure and Interpretation of Computer Programs, uses LISP (actually Scheme). There are quite a few LISP fanatics who passionately feel it is still the best programming language made, citing such reasons as the simplicity of writing an interpreter for it. However, that textbook is pretty difficult. The authors didn't appreciate how hard recursion can be for many students to understand, and LISP and functional programming in general uses recursion so heavily it's the proverbial hammer for every nail of a programming problem.

Since then, programming languages have improved. Still not good enough for the textbook, but closer.

Re:Unfortunately no and I have a reason

[shaitand]

Since the safety checks are language dependent and aren't actually related to the algorithm logic, yes, that is better. This isn't a copy and paste recipe book. Learn the algorithm logic from the book then write your own implementation in the language of choice.

Re: Unfortunately no and I have a reason

[Anonymous Coward]

So you can't read them?

They are some of the most valuable books I'be ever owned. Whether during programming, developing FPGA logic or just trying to have a method of proving some of my algorithms. TAOCP is invaluable.

Computer science is still... well science and TAOCP is a cornerstone of computer science. You're confusing computer science and application programming.

There are certainly better places to learn the basics. Like for example, what is a red black tree? But TAOCP is where you understand them.

And I think his pseudo-computer concept was nifty. As for FORTRAN, all the fortran developers I know are generally slobs. They'd never touch these books.

Re: Unfortunately no and I have a reason

[RabidReindeer]

I can't say I've ever read Knuth in the literary sense. It's more of the ultimate reference.

Thankfully, I no longer have to construct sorts, searches, random number generators, etc. every time I write a program, since modern-day language systems come pre-supplied. However, someone has to implement those pre-supplied algorithms, and that someone almost certainly referenced Knuth. He has provided a concise, well-explained collection of analyses, discussions and sample implementations of many of the most important functions needed by almost everyone in the software development field.

The downside of it is MIX. I understand the reason Knuth created MIX, but MIX is an assembly language and not even a commonly-used one (and intentionally so). I know that there are many who think that the purpose of computers is to run machine (assembly) language, but they're wrong.

The purpose of computers is to run software. How it runs the software is secondary. You can see this in the fact that some machines include in their instruction set specialized functions related to specific abstract features. The Prime Computer instruction set had machine-language implementations of the FORTRAN 3-way branch. I think it was Honeywell that had an OS task dispatcher function implemented as a machine-language instruction. The Inter iAPX432 was designed to run Ada, the IBM System/360 had the Translate instructions, and the IBM zSeries has a major subset of the Unix stdlib implemented as CISC instructions, including a few of the Knuth algorithms.

Keeping software as a set of bits corresponding to primitive functions is convenient for implementing von Neumann machines, but it should be realized that it's the means and not the end, and when scaled, tends to lose the abstract picture in the minutae. If minutae were the end of it, one should be programming microcode and manually switching gates - on many machines, the "machine language" is itself an abstraction interpreted via microcode.

I've often complained that one of the biggest annoyances in IT is that you can pop out a prototype GUI in a day or 2 and everybody thinks it should go to full production next Thursday, where no one in their right mind would ever expect a scale cardboard model of a building or bridge to be ready for use in such time.
But there's a similar break in education in that in most cases CIS courses use a "practical" language instead of an abstract one.

While assembly language was very common when Knuth wrote Volumes I-III, he was aware that there was no universal high-level language any more that there was a universal low-level one, which was another reason he invented MIX. Even academically-inclined languages such as Modula ultimately detoured into practical use, warping their abstraction. And, although ideological purity makes me projectile-vomit, when you're dealing with abstract concepts, I prefer to keep things truly abstract. Otherwise it warps one's approach to later solutions.

Djisktra did. in fact attempt an abstract high-level language in his "A Discipline of Programming", although it has some odd warts of its own. Personally, I'd vote for Ada, because while the last time I actually ran Ada, it nearly burned out the bearings on a mid-line IBM mainframe, it is the only common language I know where values and functions are assigned ranges and domains - an essential concept that is taught at the very beginning of differential calculus classes, but not nearly well-stressed enough in most CIS curricula. Were it otherwise, perhaps fewer satellites would have been destroyer.

Ada, incidentally, is part of the gcc/gnat toolset available on almost any Linux development system and modern-day PCs are considerably more powerful than a 1990 mid-level IBM mainframe (but then again, probably so are most cellphones), so anyone who's curious can explore.

Re:Unfortunately no and I have a reason

[luis_a_espinal]

presented .... without any boilerplate code, overhead, or worries about limitations, no need for tedious checks for array out of bounds, numeric overflow, or out of memory, or invalid input.

Wait - did I read that correctly? "without any boilerplate code, overhead, or worries about limitations, no need for tedious checks for array out of bounds, numeric overflow, or out of memory, or invalid input" = improved textbook? Aren't these the attack vectors used by malware and viruses today?

Everything you mentioned are supposed to be a given. A person who needs explicit indication of them are not at the level required to use a book like CLRS. I don't mean it as an insult, but as an observation.

Moreover, many of the checks you mention are handled by constructs and idioms that are language dependent. For example, boundary checking in C will be different from, say, Ada or Java, let alone something like Ruby or LISP.

Also, when you are stuying algorithms at that level, you are assumed to have a certain maturity that makes reference to such things irrelevant. Think of it like this: If you are learning how to solve quadratic equations, you do not need a lesson in adding fractions, do you?

Same principle applies here. When you are taking a book like CLRS, it is to study the mathematical properties of algorithms.

I would say that a there is a more hands-on book that directly addresses these concerns: O'Reilly's Algorithms in a Nutshell. This is a really nice pocket book.

Torn between reading and doing

[mykepredko]

I read the first three books in University and did examples from the first two when I started debating with myself, friends and professors, is it better to have the ultimate reference or be able to create code on your own as the requirements come up?

Over the thirty plus years since, I'm happy to say that volume two and three have gotten pretty ratty as I've used them as references (along with "Programming in C", 2nd edition) so I feel like I've struck the right balance (for me) between reading them, using them as reference and creating my own code/algorithms.

Read the first volume

[guruevi]

It's really great reading if you do stuff like program low-level (think C, Assembler), efficient programming or do stuff close to the hardware level (such as microprocessors). It describes the very low level of a program and a computer.

If you're into a higher level of programming (Java, C#, Python etc), unless you're building libraries for it, it is probably going to confuse you, most of the 'hard stuff' is (double precision, floating point, sorting and searching through lists ...) abstracted away. Obviously 'someone' has to know how it works in the end, someone has to write the compilers, I haven't started on the rest of the volumes because that's not "me".

You should understand how computers work before you start reading these, I've been in the 'business' for 20 years, I've read it 3 times just to get a basic grasp on the first volume.

A SkyRim Read? Then Yes.

[xxxJonBoyxxx]

I read the three volumes like I read any book in SkyRim: I opened the cover, got my +1 level in computer science, dropped it and hit it with a fireball.

Parts

[Erich]

TAOCP is a great reference. There are some really important things that are pretty good for someone who wants to be a professional software engineer.... 0) understanding how algorithms execute on a processor. While MIX is behind the times, (and MMIX is ahead of the times in many ways) understanding how an algorithm executes on a processor is important. I think Knuth really did the right thing in not selecting the language of the day. 1) algorithm reference. If you need to understand an algorithm, or choose between a family of algorithms, it is often a great place to find the art. 2) The humor is pretty good, at least to me. Done get me wrong, it's on a humor book, but there is wittiness and puns and some running gags... 3) It's always good to have some humility, and reading TAOCP always makes me a little more humble. It's worthy of a place on your shelf.

Re:Hell no

[Tablizer]

Programming isn't terribly complex. If you want to program, just do it.

It's not complex if you merely want it to run, but if you want flexible, maintainable, and readable code, then it is complex.

I have read some

[hgriggs]

I have them. I have studied small parts of some of them. I have been delving into them over 30 years.

For day to day programming, I do not need or use the detail in those books.

At various times in the past, I have delved into library writing, and then they were very helpful, mostly in understanding issues and problems that I had not thought about. But I think time has moved on. Hardly anyone needs the details in those books, and in many cases, some classes of problems are well solved.

Looking back, I am glad that I studied some parts. But today I would not recommend them. Unless you really wanted to look back at history.

Re:Hell no

[Tough Love]

Nah, I've been programming longer than Knuth has, starting with machine language. You just need to think procedurally.

In your case, it sounds more like "sporadically".

I have, not worth it

[AuMatar]

Don't get me wrong, Knuth is a genius. If you need to do deep research on sorting algorithms, definitely read it. If you want to do CS research and need to learn how to read research papers, its a good start. But you aren't going to get any deep insights on how to write a good program from it. Its too academic and far too focused on deep research. And even for the topics it does cover, unless you want to do research on how to really optimize the hell out of them you're better off using tutorials written for a more practical level.

Maybe

[kwerle]

I wasn't sure if I'd read 'em. I know a friend/colleague (who I regard highly) who has - and I think he thinks highly of them. But he also has terrible taste in movies.

A quick google search landed me at http://broiler.astrometry.net/...

I have not read it.

I've been coding professionally for 25-30 years, depending on how you count. I studied CS in college. I've read a few outstanding books on the subject since then.

I don't have the patience for these, and I suspect I'm not going to miss out on much.

On the other hand, I long ago came to the conclusion that I'm really not interested in low level code. Give me a nice high level language with nice high level functions and features and I'm a happy coder. That's not to say that I don't understand O notation or the costs behind the complexity - but it is to say that I know when to use a drill and when to use a power saw - but I don't want to build either of 'em.

Maybe you're into the nitty gritty. Or maybe you like bad movies.

Check your local tech library and see if you can check out a copy. Or ebay 'em for $20-40/volume. Or if the pdf strikes your fancy, maybe take the plunge.

Re:Hell no

[0100010001010011]

110010001000 caught at work