Beware of bugs in the above code; I have only proved it correct, not tried it.
Donald Knuth's webpage states the line was used to end a memo entitled Notes on the van Emde Boas construction of priority deques: An instructive use of recursion (1977)
I can’t be as confident about computer science as I can about biology. Biology easily has 500 years of exciting problems to work on. It’s at that level.
The psychological profiling [of a programmer] is mostly the ability to shift levels of abstraction, from low level to high level. To see something in the small and to see something in the large.
The important thing, once you have enough to eat and a nice house, is what you can do for others, what you can contribute to the enterprise as a whole.
Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration.
How can you own [...] numbers? Numbers belong to the world.
In his video account on the creation of TeX, he comments that Xerox offered to allow him to use their equipment, but that the fonts he created would belong to them.
In fact, my main conclusion after spending ten years of my life working on the TEX project is that software is hard. It’s harder than anything else I’ve ever had to do.
If you find that you're spending almost all your time on theory, start turning some attention to practical things; it will improve your theories. If you find that you're spending almost all your time on practice, start turning some attention to theoretical things; it will improve your practice.
Donald Knuth, quoted in: Arturo Gonzalez-Gutierrez (2007) Minimum-length Corridors: Complexity and Approximations. p. 99
In a way, you'd say my life is a convex combination of English and mathematics. ... And not only that, I want my kids to be that way: use left brain, right brain at the same time – you got a lot more done. That was part of the bargain.
I am assuming that God exists and I am glad that there is no way to prove this. [Because] I would run through the proof once, and then I'd forget it, and I would never speculate about spiritual things and mysteries otherwise. And, I think, my life would be very incomplete.
I came to philosophy finally phrased as "0.8 is enough". … If I had a way to rate happiness, I think it's a good design to have an organism that's happy about 80% of the time. If it was 100% of the time, it would be like everybody's on drugs and everything collapses and nothing works because everybody is just too happy. … There are times when I am down and I know that I've actually been programmed to be depressed a certain amount of time.
By understanding a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality.
Vol. I, preface (October 1967) to the first edition. (p. x 1973, p. ix 1997)
An algorithm must be seen to be believed.
Vol. I, Fundamental Algorithms, Section 1.1 (1968)
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird.
Vol. I Fasc. 1, "MMIX, a RISC computer for the new millennium"
Random numbers should not be generated with a method chosen at random
Vol. II, Seminumerical Algorithms
The sun comes up just about as often as it goes down, in the long run, but this doesn't make its motion random.
Vol. II, Seminumerical Algorithms, Section 3.3.2 part B, first paragraph (1969)
The reason is not to glorify "bit chasing"; a more fundamental issue is at stake here: Numerical subroutines should deliver results that satisfy simple, useful mathematical laws whenever possible. [...] Without any underlying symmetry properties, the job of proving interesting results becomes extremely unpleasant. The enjoyment of one's tools is an essential ingredient of successful work.
Vol. II, Seminumerical Algorithms, Section 4.2.2 part A, final paragraph [Italics in source]
Any inaccuracies in this index may be explained by the fact that it has been sorted with the help of a computer.
Vol. III, Sorting and Searching, End of index (1973)
Science is knowledge which we understand so well that we can teach it to a computer; and if we don't fully understand something, it is an art to deal with it.
p. 668
In this sense, we should continually be striving to transform every art into a science: in the process, we advance the art.
p. 669 [italics in source]
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
p. 671
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
Variant in Knuth, "Structured Programming with Goto Statements". Computing Surveys6:4 (December 1974), pp. 261–301, §1. doi:10.1145/356635.356640
Knuth refers to this as "Hoare's Dictum" 15 years later in "The Errors of Tex", Software—Practice & Experience19:7 (July 1989), pp. 607–685. However, the attribution to C. A. R. Hoare is doubtful.
All three of these papers are reprinted in Knuth, Literate Programming, 1992, Center for the Study of Language and Information ISBN 0937073806
To summarize: We have seen that computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty. A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better. Therefore we can be glad that people who lecture at computer conferences speak of the state of the Art.
p. 673 [italics in source]
Literate Programming (1984)
Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
"Literate Programming", The Computer Journal27 (1984), p. 97. (Reprinted in Literate Programming, 1992, p. 99.)
For his major contributions to the analysis of algorithms and the design of programming languages, and in particular for his contributions to the "art of computer programming" through his well-known books in a continuous series by this title.