Why I run away from Knuth | Hacker News Reader

Why I run away from Knuth

lispmachine.wordpress.com

22 pointsknight1740 comments

There is no substantive content about any of Knuth's books in this article. I don't believe the author has read any of the books - most people commenting on Knuth haven't. The piece is just incoherent rambling about how math is hard - NOT something that should be voted to #1 on the front page of anywhere, especially HN.yc.

The following excerpt sums it up:

"...I am an average man, with an average IQ. I could have have failed the Mathematics exam of 10th class in 1996. I was very poor at Mathematics and I was expecting only 22 or 34 marks out of 100 and anything less than 33 means you have failed the exam but I purchased 2 very heavy-books of Mathematics, which our teacher called best references books for 10th class and studied them at the cost of my health for 2 months and then I got 83 marks but those health problems, the pain in the neck are still with me after 12 years ) . Since I was weak in Mathematics may be thats why I don’t like Knuth’s style ..."

That's what I thought after reading the first paragraph. If anything, I find Knuth's books to among the most approachable, partially because he has a good sense of humor, but mostly because Knuth writes in a very conversational style.

Now what I _really_ want is a way to identify all the people who voted this story and substract their votes from all future posts. Can I? Please?

This was my cue to take my exit to the back button:

  Though they were programming books but they were not 
  written to show you the reality of what happens when you 
  use scp to copy file over a network. *How that scp program 
  looks like and Why it is so strange at 1st.* Those books 
  will never tell you ( in code ) that their could be 
  errors, their could be failures, their could be some 
  problem in making a connection, that, for obvious 
  reasons, you have to use ” -ansi -pedantic -Wall -Wextra” 
  while working with GCC but all we learned were TURBO C 
  and a book on DOS 6.2 ( this shitty-book had cost me my 
  precious 600 rupees )I put Knuth in the same category. He 
  just explains, explains and explains the algorithms, with 
  100% Mathematics, in the most detailed manner ever done 
  and leaves the applications of those algorithms up to 
  you. They are not designed for people like me.

He would rather read a book that tells him about the possible errors that the scp program might print out instead of a Knuth book. Got it. Back to my regularly scheduled programming.

(You know that you used "queue" when you meant "cue" right? Not trying to make fun of you, just pointing out that they're homophones with different meanings and it's kind of jarring to read the wrong one)

Yep. Good catch. I know the difference, but don't always catch myself before the wrong word gets to my fingertips.

Were you previously working on a scheduling algorithm?

"Those books will never tell you ( in code ) that their could be errors, their could be failures, their could be some problem in making a connection"

There could even be wrong usage of "their" 3 times in a row in an error message!

I've always thought Knuth was quite entertaining and droll, even in his scientific work. Like the time he showed up for Randall Munroe's Google talk and asked about the n log (log n) sort algorithm discovered by his dark apprentice Elaine. http://xkcd.com/342/

I think the problem with reviews like this one that say "I wish this guy had written a different book" is that they refuse to take the work and the author on their own terms. TAoCP is obviously on a mission to rigorously define algorithms at the heart of computer science, compare them, and make provable statements about their complexity. On those grounds, none of the pedagogical texts the author prefers holds a candle to the blinding glory of TAoCP. (Of course, they weren't really trying to.)

It's the same with all kinds of art. Come to it full of expectations that the art doesn't fulfill, and you won't make the connection... but that's not the art's fault.

The basic claim here seems to be that there is little use for deep, rigorous algorithmic thinking in the monotonous day to day work of business applications that constitutes the majority of paid programming work.

Why does this lessen the value of books like Knuth and CLRS? And what does it say about the boring projects the author works on?

The truth is, in a business app, wiring up the interface to a database is usually not the hard part. The hard part is dealing with political bullshit, dealing with people, making sure the interface is right, gathering domain knowledge and understanding users' needs, deciding what features matter and which don't given your budget and time constraints, and other things that have little to do with J2EE, .Net, and other ephemeral daycoder staples: these are high-level issues anti-intellectual philistines like the author of this post flatly refuse to acknowledge the significance of.

It is possible to artificially fabricate situations in a business where invoking deep, powerful ideas from computer science is necessary. But often there is a much simpler solution that necessitates much simpler techniques: this is the right thing to go for, even though solving the wrong problem may have an appealing, elegant solution that proves that you're a really smart person. Knowing when to be a fancypants computer science whiz and when to make a 5 line call to an existing library is really where maturity and mastery come in to software development, IMO.

Not unsurprisingly, articles like this say more about the author than about Knuth.

Knuth is not for everybody. No question about that. But for people who are interested in the area he covers, there is no one better.

"Not unsurprisingly"? That hurts my head.

Yeah, one negative too many, huh? Well, I guess you can save the extra one for next time.

You shouldn't use no triple negatives neither.

Come on, most of us have had some form of logic class. It shouldn't be that hard. !(!p) = p.

Natural language != logic.

There's a fat chance you'll ever have a slim chance of applying that universally to natural language.

I understand. You are not in a humorous mood.

There's not a slim chance you'll never have a fat chance of unapplying that locally to unnatural language.

some like water, some like wine. to each his own.

The most serious problem with Knuth's TAOCP books is that they are severely out of date. For example, Volume III (searching and sorting) only has two paragraphs that even mention virtual memory and memory caches at all. That is a huge issue--if you have a sorting problem that is bad enough that you need to break out Knuth, then you probably need to know to implement the algorithms in a cache-oblivious manner. Further, you need to know when you can rely on the VMM (mmap and swap) and when you must explicitly manage disk-based data separately from RAM-based data.

I doubt I agree. Knuth covers the fundamental, distilled algorithms very comprehensively. I really don't think covering VM, cache issues/width of cache lines, as well as virtues of pinning pages in memory is completely in his scope. If he did that, he'd have to talk about architectural issues such as out of order execution and depth of pipe-lines, which he obviously has no interest in since he developed his own `ideal' (M)MIX architecture specifically for the books.

I feel that the best way to approach actual algorithm implementation is to see what Knuth has to say about it in terms of virtues of some algorithms vs others and then to study the environment it will be running on to tweak the general algorithm.

I have to agree with Brian... Caching is not a purely practical concern; it is important to the analysis of algorithms as well. It looks like Knuth agrees:

http://www.softpanorama.org/Lang/c.shtml

Donald: I mentioned earlier that MMIX provides a test bed for many varieties of cache. And it’s a software-implemented machine, so we can perform experiments that will be repeatable even a hundred years from now. Certainly the next editions of Volumes 1-3 will discuss the behavior of various basic algorithms with respect to different cache parameters.

In Volume 4 so far, I count about a dozen references to cache memory and cache-friendly approaches (not to mention a "memo cache," which is a different but related idea in software).

I stand corrected.

I remember reading Volume 1 where he notes how he is not happy with current architectures, which is why he introduced MIX. I guess I wrote my earlier comment from how I look at Knuth, perhaps not how it was intended. Haven't seen Volume 4 yet though.

You were not misremembering. Volume 4 is in beta, and a planned rewrite of Volumes 1 to 3 (after Volume 5! eta: 2015) to take advantage of MMIX (the new version of the MIX language) is not even on the horizon yet.

http://www-cs-staff.stanford.edu/~uno/taocp.html

At the risk of being labeled a heretic, Knuth is great and all, but, in a rapidly expanding field, you can't just sit down and "describe the whole thing", or even the algorithms of the whole thing. Knowledge in the field is a hyper linear curve, and the ability of one aging person to describe the sum total of all knowledge in said field is pretty much linear. That's a recipe for failure, at least in terms of the stated goals. There is something... vaguely dubious to me about how Knuth has approached the whole project, including stopping for N years to work on TeX just to typeset it. I guess you can give him for trying, and in trying, producing some excellent work, but perhaps a different approach might have yielded other benefits.

I agree to a certain extent. All sciences specialize as they mature. Computer scientists looking to make their mark are inevitably driven out from the core into security, bioinformatics, robotics, data mining, distributed systems, what have you.

I don't know Knuth's mind exactly, but it seems to me he decided to set up shop at the core, at theory and algorithms, to set the science on a solid foundation going forward. So it's fundamental algorithms, arithmetic, searching, sorting, and lately graphs and combinations.

There are enough people writing in their specialties, and there will always be incentives to go baroque and novel. That's how we get stupid stuff like my thesis, or 8% faster neural network training, or the paper on implementing a Turing machine in C++ templates.

http://ubiety.uwaterloo.ca/~tveldhui/papers/2003/turing.pdf

It takes a special kind of person to forge ahead slowly, for decades, on the field-defining work that he does. The other kinds of scientists (and software engineers, for that matter) are all too easy to find.

http://edward.oconnor.cx/2002/04/don-knuth-sells-out

Can somebody who upvoted this tell me why? It doesn't make any sense to me, other than that it points out that Knuth is mathy (holy cow!)

What about all those $2.56 checks you could be getting?

Despite some overlap, there is a difference between computer science and programming. Knuth concentrates on the former, so you'll be disappointed with his books if you're only looking for the latter... The title "The Art of Computer Programming" is somewhat misleading in this regard.

  (if pointy-haired-boss
    (progn 'do-politics)
    (format t "write code & enjoy ;-)"))

You don't need the progn. :)

Exactly what I thought when I read the article. It sounds like he's heard that Lisp is cool, so he pretends he is a Lisp expert, but he has no clue about that (or Knuth). Sad.

Anyway, I was thinking he meant funcall instead of progn, but in that case he should just have written (do-politics).

Finally, shouldn't that be pointy-haired-boss-p? ;)

shouldn't that be pointy-haired-boss-p? ;)

Heh. I almost thought so too, but the variable could be referencing the boss himself rather than information about his existence. Somehow I think it's more Lispy that way.

And (progn 'do-politics) does look like a mistake for (do-politics) but then again I kind of like the fact that the form evaluates to a useless symbol in the pointy-haired case.

Really, there are all kinds of things one could say about this little expression. One could write an entire critique. :)

Upon further reflection, how about:

  (if (pointy-haired-p boss) ...

Ah, coding by committee. How pointy-haired of us :)

Must I have a boss?

  (if (and boss (pointy-haired-p boss)) ...

coding by committee. How pointy-haired of us

I object. This is sarcastic pair programming!

I thought K&R2 was pretty easy to read and understand, hardly, "painful and difficult".

I've worked with Java and C++ for several years, but I need to learn C for a project I'm doing this summer. Having heard many good things about K&R2, I picked it up and I'm astounded at the clarity of the piece.

By today's standards, it does have a few fairly academic examples (if I wanted to convert fahrenheit to celsius, I would use google), but otherwise it has excellent examples of functional code written in a concise style to clearly demonstrate how to use the language to get things done.

The author mainly seems to be implying that K&R2 is "totally not related to what [the author is] doing right now as a programmer in some company."

Agreed. K&R is one of the best teaching texts I've ever read. It's paced wonderfully, and explained extremely clearly. I had tried numerous other C texts before getting K&R, and never managed to get very far...pointers, in particular, seem to be very poorly covered by everybody else.

The author wants the knoweledge that can be immediately applied; in my opinion it's the common mistake: without understanding the basics (which is full of Math's) all what you'll have is the set of recipes for your everyday tasks, and won't be able to master really challenging problems.

In rigorous areas like math and CS, simple things often sound difficult because nobody tried hard enough to simplify the presentation. Some books hit the sweet spot, like Ken Binmore "Fun and Games" or Cormen, Leiserson, Rivest "Introduction to Algorithms". Knuth doesn't.

Reply on news.ycombinator.com