K老在拿图灵奖时的发言：Computer Programming as an Art

很多话说得很透彻，把一些觉比较精彩的摘抄一下。

... It seems to me that if
the authors I studied were writing today, they would agree with the following
characterization: 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. Since the notion of an algorithm or a computer program provides
us with an extremely useful test for the depth of our knowledge about any given
subject, the process of going from an art to a science means that we learn how
to automate something.

Artificial intelligence has been
making significant progress, yet there is a huge gap between what computers can
do in the foreseeable future and what ordinary people can do. The mysterious
insights that people have when speaking, listening, creating, and even when they
are programming, are still beyond the reach of science; nearly everything we do
is still an art.

... Fifteen years ago computer programming
was so badly understood that hardly anyone even thought about proving programs
correct; we just fiddled with a program until we "knew" it worked. At that time
we didn‘t even know how to express the concept that a program was correct, in
any rigorous way. It is only in recent years that we have been learning about
the processes of abstraction by which programs are written and understood; and
this new knowledge about programming is currently producing great payoffs in
practice, even though few programs are actually proved correct with complete
rigor, since we are beginning to understand the principles of program structure.
The point is that when we write programs today, we know that we could in
principle construct formal proofs of their correctness if we really wanted to,
now that we understand how such proofs are formulated. This scientific basis is
resulting in programs that are significantly more reliable than those we wrote
in former days when intuition was the only basis of correctness.


... Of all the books I‘ve mentioned, Mueller‘s comes
closest to expressing what I want to make the central theme of my talk today, in
terms of real artistry as we now understand the term. He observes: "It was once
thought that the imaginative outlook of the artist was death for the scientist.
And the logic of science seemed to spell doom to all possible artistic flights
of fancy." He goes on to explore the advantages which actually do result from a
synthesis of science and art.

A scientific approach is
generally characterized by the words logical, systematic, impersonal, calm,
rational, while an artistic approach is characterized by the words aesthetic,
creative, humanitarian, anxious, irrational. It seems to me that both of these
apparently contradictory approaches have great value with respect to computer
programming.

... When I speak about computer programming as
an art, I am thinking primarily of it as an art form, in an aesthetic sense. The
chief goal of my work as educator and author is to help people learn how to
write beautiful programs.

... programming can give us both
intellectual and emotional satisfaction, because it is a real achievement to
master complexity and to establish a system of consistent rules.


... I can still remember the great thrill it was for me to
read the listing of Stan Poley‘s SOAP II assembly program in 1958; you probably
think I‘m crazy, and styles have certainly changed greatly since then, but at
the time it meant a great deal to me to see how elegant a system program could
be, especially by comparison with the heavy-handed coding found in other
listings I had been studying at the same time. The possibility of writing
beautiful programs, even in assembly language, is what got me hooked on
programming in the first place.

... When we apply our own
prejudices to "reform" someone else‘s taste, we may be unconsciously denying him
some entirely legitimate pleasure. That‘s why I don‘t condemn a lot of things
programmers do, even though I would never enjoy doing them myself. The important
thing is that they are creating something they feel is
beautiful.

... There are many senses in which a program can
be "good," of course. In the first place, it‘s especially good to have a program
that works correctly. Secondly it is often good to have a program that won‘t be
hard to change, when the time for adaptation arises. Both of these goals are
achieved when the program is easily readable and understandable to a person who
knows the appropriate language.

Another important way for a
production program to be good is for it to interact gracefully with its users,
especially when recovering from human errors in the input data. It‘s a real art
to compose meaningful error messages or to design flexible input formats which
are not error-prone.

Another important aspect of program
quality is the efficiency with which the computer‘s resources are actually being
used. I am sorry to say that many people nowadays are condemning program
efficiency, telling us that it is in bad taste. The reason for this is that we
are now experiencing a reaction from the time when efficiency was the only
reputable criterion of goodness, and programmers in the past have tended to be
so preoccupied with efficiency that they have produced needlessly complicated
code; the result of this unnecessary complexity has been that net efficiency has
gone down, due to difficulties of debugging and
maintenance.

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.

We shouldn‘t be penny wise and pound
foolish, nor should we always think of efficiency in terms of so many percent
gained or lost in total running time or space. When we buy a car, many of us are
almost oblivious to a difference of $50 or $100 in its price, while we might
make a special trip to a particular store in order to buy a 50 cent item for
only 25 cents.

... we should make use of the idea of
limited resources in our own education. We can all benefit by doing occasional
"toy" programs, when artificial restrictions are set up, so that we are forced
to push our abilities to the limit. We shouldn‘t live in the lap of luxury all
the time, since that tends to make us lethargic. The art of tackling
miniproblems with all our energy will sharpen our talents for the real problems,
and the experience will help us to get more pleasure from our accomplishments on
less restricted equipment.

In a similar vein, we shouldn‘t
shy away from "art for art‘s sake"; we shouldn‘t feel guilty about programs that
are just for fun. ... "there is nothing, the utility of which is more
incontestable. To what shall the character of utility be ascribed, if not to
that which is a source of
pleasure?"

最后一节探讨编程工具的优劣问题，及优质的编程工具会给程序员带来的愉悦，好的工具应该给程序员更多细节的反馈而不是把他们当傻子屏蔽掉所有细节等等。

原文地址：http://www.paulgraham.com/knuth.html