On Friday, 27 March 2015 at 06:31:40 UTC, Laeeth Isharc wrote:
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.
The whole art/science vein of these Knuth quotes seems like a lot
of BS, trying to situate computer programming in the
long-standing and overblown science/humanities "divide."
He characterizes the artistic approach as "aesthetic, creative,
humanitarian, anxious, irrational." But of course, there are
aesthetic elements to any human endeavor: the scientific camp
simply favors different aesthetics. Anything beyond the most
rudimentary science requires a great deal of imagination and
creativity: it just requires learning a great deal of technical
concepts first that may be harder to manipulate mentally.
Of course art is "humanitarian," as it's subjective and aimed at
a human audience. Hard to argue the science that brought us
modern civilization isn't a hundred times more humanitarian, far
beyond the superficial sheen of "humanitarian" art he's talking
about. "Anxious" and "irrational" are human emotions often
possessed by artists, not qualities applied to art, fitting given
they cannot produce anything of the great value of science.
He is really arguing against the likely prevailing view of the
time of programming as a dry, functional process and pointing out
and pushing for the aesthetic qualities in programming, which is
all fine. But he then gets caught up in the false dichotomy and
claptrap of the science/humanities debate, a lot of mumbo jumbo
that is not worth getting caught up in.
He should have stuck to calling for more aesthetically pleasing
programming languages and tools- the best contribution he could
have made is to more precisely define what he thinks that
aesthetic should look like- instead of needlessly laying out
worthless and overly simplistic platonic definitions like the
mindsets of Art and Science. At least his piece gave us that
"premature optimization" line, which is worth far more than
everything around it.
There is a great desire by programmers and many other professions
to see themselves as "artists." Well, there is art in
everything, but they're not, and they should be grateful they
aren't, or they wouldn't be paid anywhere near so well. ;)
