I've read it before, but since it's been a while I've just skimmed through it again. Here are a few key quotations, followed by my commentary:
It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail. (p 268)
Despite this concern with efficiency, I should actually have written the first draft of Example 3 without that go to statement, ... since this formulation abstracts the real meaning of what is happening. (p 270)
[W]e shouldn't merely remove go to statements because it's the fashionable thing to do; the presence or absence of go to statements is not really the issue. The underlying structure of the program is what counts, and we want only to avoid usages which somehow clutter up the program. (p 275)
We need to be subconsciously aware of the data processing tools available to us, but we should strive most of all for a program that is easy to understand and almost sure to work. (p 294)
Engineering has two phases, structuring and integration; we ought not to forget either one, but it is best to hold off the integration phase until a well-structured prototype is working and understood. (p 295)
Standard operating procedure nowadays is usually to hand code critical portions of a routine in assembly language. Let us hope such assemblers will die out, and we will see several levels of
language instead: [...] With an integrated system it will be possible to do debugging and analysis of the transformed program using a higher level language for communication. (p. 295)
Knuth's primary concern throughout the entire article is that program text should clearly communicate intent between programmers, which the contemporary trend of removing gotos sometimes hindered. His secondary concern is on program efficiency, and he notes a few points regarding it:
- Most performance gains can be obtained by optimizing a few small critical sections.
- Programmer intuition fails when attempting to identify these critical sections, and program analysis is needed instead.
- The optimizations needed often compromise clarity, so the optimized version should be considered a production artifact instead of the primary record of the program's purpose.
Overall, Knuth is arguing for a 3-step process to writing programs:
- Write a program that is obviously correct
- Use program analysis tools to identify the parts of the program from (1) that are worth optimizing, at a cost of clarity
- Optimize those parts so identified
Furthermore, he notes that the optimizations required are often quite mechanical in nature, and hopes that future tooling will be able to take care of that part for us.
Or, in even shorter form,