
Why I run away from Knuth - knight17
http://lispmachine.wordpress.com/2008/05/08/why-i-run-away-from-knuth/
======
menloparkbum
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 ..."

~~~
donw
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.

------
aggieben
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.

~~~
llimllib
(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)

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

~~~
brentr
Were you previously working on a scheduling algorithm?

------
msg
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.

------
henning
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.

------
michael_dorfman
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.

~~~
jobeirne
"Not unsurprisingly"? That hurts my head.

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

~~~
maw
You shouldn't use no triple negatives neither.

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

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

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

------
briansmith
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.

~~~
yan
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.

~~~
jcl
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)._

~~~
yan
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.

~~~
msg
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>

~~~
davidw
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.

~~~
msg
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>

------
llimllib
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!)

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

------
jcl
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.

------
gruseom

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

You don't need the progn. :)

~~~
jrockway
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_? ;)

~~~
gruseom
_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. :)

~~~
jrockway
Upon further reflection, how about:

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

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

~~~
gruseom
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!

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

~~~
sdp
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."

------
alexk
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.

------
cousin_it
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.

