An old essay that may yet be relevant today at a time when
intellectual fashion has continued in the direction he was moved
to address in his speech.
"there is a way to make a big improvement: it is still a pleasure
to do routine jobs if we have beautiful things to work with. For
example, a person will really enjoy wiping off the dining room
table, day after day, if it is a beautifully designed table made
from some fine quality hardwood."
"Language designers also have an obligation to provide languages
that encourage good style, since we all know that style is
strongly influenced by the language in which it is expressed. The
present surge of interest in structured programming has revealed
that none of our existing languages is really ideal for dealing
with program and data structure"
http://www.paulgraham.com/knuth.html
CACM, December 1974
When Communications of the ACM began publication in 1959, the
members of ACM'S Editorial Board made the following remark as
they described the purposes of ACM'S periodicals [2]:
"If computer programming is to become an important part of
computer research and development, a transition of programming
from an art to a disciplined science must be effected."
Such a goal has been a continually recurring theme during the
ensuing years; for example, we read in 1970 of the "first steps
toward transforming the art of programming into a science" [26].
Meanwhile we have actually succeeded in making our discipline a
science, and in a remarkably simple way: merely by deciding to
call it "computer science."
Implicit in these remarks is the notion that there is something
undesirable about an area of human activity that is classified as
an "art"; it has to be a Science before it has any real stature.
On the other hand, I have been working for more than 12 years on
a series of books called "The Art of Computer Programming."
People frequently ask me why I picked such a title; and in fact
some people apparently don't believe that I really did so, since
I've seen at least one bibliographic reference to some books
called "The Act of Computer Programming."
In this talk I shall try to explain why I think "Art" is the
appropriate word. I will discuss what it means for something to
be an art, in contrast to being a science; I will try to examine
whether arts are good things or bad things; and I will try to
show that a proper viewpoint of the subject will help us all to
improve the quality of what we are now doing.
...
As I was looking up these things about the meanings of "art," I
found that authors have been calling for a transition from art to
science for at least two centuries. For example, the preface to a
textbook on mineralogy, written in 1784, said the following [17]:
"Previous to the year 1780, mineralogy, though tolerably
understood by many as an Art, could scarce be deemed a Science."
According to most dictionaries "science" means knowledge that has
been logically arranged and systematized in the form of general
"laws." The advantage of science is that it saves us from the
need to think things through in each individual case; we can turn
our thoughts to higher-level concepts. As John Ruskin wrote in
1853 [32]: "The work of science is to substitute facts for
appearances, and demonstrations for impressions."
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.
...
From this standpoint it is certainly desirable to make computer
programming a science, and we have indeed come a long way in the
15 years since the publication ot the remarks I quoted at the
beginning of this talk. 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.
...
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. It is for this reason I was
especially pleased to learn recently [32] that my books actually
appear in the Fine Arts Library at Cornell University. (However,
the three volumes apparently sit there neatly on the shelf,
without being used, so I'm afraid the librarians may have made a
mistake by interpreting my title literally.)
My feeling is that when we prepare a program, it can be like
composing poetry or music; as Andrei Ershov has said [9],
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.
Furthermore when we read other people's programs, we can
recognize some of them as genuine works of art. 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.
Some programs are elegant, some are exquisite, some are
sparkling. My claim is that it is possible to write grand
programs, noble programs, truly magnificent ones!
..
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. My point is
that there is a time and place for efficiency; I have discussed
its proper role in my paper on structured programming, which
appears in the current issue of Computing Surveys [21].
...
One rather curious thing I've noticed about aesthetic
satisfaction is that our pleasure is significantly enhanced when
we accomplish something with limited tools. For example, the
program of which I personally am most pleased and proud is a
compiler I once wrote for a primitive minicomputer which had only
4096 words of memory, 16 bits per word. It makes a person feel
like a real virtuoso to achieve something under such severe
restrictions.
...
When we teach programming nowadays, it is a curious fact that we
rarely capture the heart of a student for computer science until
he has taken a course which allows "hands on" experience with a
minicomputer. The use of our large-scale machines with their
fancy operating systems and languages doesn't really seem to
engender any love for programming, at least not at first.
...
How did they develop their skill? The best film makers through
the years usually seem to have learned their art in comparatively
primitive circumstances, often in other countries with a limited
movie industry. And in recent years the most important things we
have been learning about programming seem to have originated with
people who did not have access to very large computers. The moral
of this story, it seems to me, is that 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.
...
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. I once got a great kick out of writing a one-statement ALGOL
program that invoked an innerproduct procedure in such an unusual
way that it calculated the mth prime number, instead of an
innerproduct [19]. Some years ago the students at Stanford were
excited about finding the shortest FORTRAN program which prints
itself out, in the sense that the program's output is identical
to its own source text.
...
Another characteristic of modern art is its emphasis on
creativity. It seems that many artists these days couldn't care
less about creating beautiful things; only the novelty of an idea
is important. I'm not recommending that computer programming
should be like modern art in this sense, but it does lead me to
an observation that I think is important. Sometimes we are
assigned to a programming task which is almost hopelessly dull,
giving us no outlet whatsoever for any creativity; and at such
times a person might well come to me and say, "So programming is
beautiful? It's all very well for you to declaim that I should
take pleasure in creating elegant and charming programs, but how
am I supposed to make this mess into a work of art?"
Well, it's true, not all programming tasks are going to be fun.
Consider the "trapped housewife," who has to clean off the same
table every day: there's not room for creativity or artistry in
every situation. But even in such cases, there is a way to make a
big improvement: it is still a pleasure to do routine jobs if we
have beautiful things to work with. For example, a person will
really enjoy wiping off the dining room table, day after day, if
it is a beautifully designed table made from some fine quality
hardwood.
...
Therefore I want to address my closing remarks to the system
programmers and the machine designers who produce the systems
that the rest of us must work with. Please, give us tools that
are a pleasure to use, especially for our routine assignments,
instead of providing something we have to fight with. Please,
give us tools that encourage us to write better programs, by
enhancing our pleasure when we do so.
It's very hard for me to convince college freshmen that
programming is beautiful, when the first thing I have to tell
them is how to punch "slash slash JoB equals so-and-so." Even job
control languages can be designed so that they are a pleasure to
use, instead of being strictly functional.
...
Some tasks are best done by machine, while others are best done
by human insight; and a properly designed system will find the
right balance. (I have been trying to avoid misdirected
automation for many years, cf. [18].)
...
Language designers also have an obligation to provide languages
that encourage good style, since we all know that style is
strongly influenced by the language in which it is expressed. The
present surge of interest in structured programming has revealed
that none of our existing languages is really ideal for dealing
with program and data structure, nor is it clear what an ideal
language should be. Therefore I look forward to many careful
experiments in language design during the next few years.
...
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 about the state of the Art.
====
https://www.simple-talk.com/opinion/opinion-pieces/don-knuth-and-the-art-of-computer-programming-the-interview/
I think of a programming language as a tool to convert a
programmer's mental images into precise operations that a machine
can perform. The main idea is to match the user's intuition as
well as possible. There are many kinds of users, and many kinds
of application areas, so we need many kinds of languages.
...
I realise this is an enormous question, but what is the link
between the design of a language and the design of software
written with that language?
DK:
The software writers who have particular ways of thinking about
algorithms need a language that matches their thoughts so that
they can efficiently transform those thoughts into working code.
Different thought processes result in different structures.
