Art and Computer Programming

Art and hand-waving are two things that a lot of people consider to go very
well together. Art and computer programming, less so. Donald Knuth put them
together when he named his wonderful multivolume set on algorithms The Art
of Computer Programming, but Knuth chose a
craft-oriented definition of art (PDF) in order to do so.

Is Programming Art?

What the heck is art anyway, at least as most people understand it? What do
people mean when they say "art"? A straw poll showed a fair degree of consensus--art is craft plus a special degree of inspiration. This pretty much explains
immediately why only art students and art critics at a certain sort of paper
favor conceptual art. Conceptual art, of course, often lacks a craft component
as people usually understand the term.

My goal here is to discover whether programming is art and whether there's anything
useful to discover by regarding it as an art. Can the concept get us out
of tight corners or resolve issues? Can it help to produce killer apps?

My goal is also to find out what some accomplished programmers think. To do
this, I sent out the following email:

I'm putting together an article for O'Reilly on the subject "art
in programming" which was prompted by Donald Knuth's three volume set in which
"art" is pretty much defined as craft ... which is pretty much not the modern
definition of the word for a lot of people.

Anyway, I'm going to ask a few developers about the concept and am after
short statements relating to whether it can be or is art, whether it is
helpful to think that it is, and whether, in certain circumstances, thinking
about it in that way (non-linearly) can be conducive to problem-solving and
possible genius solutions!

OK, this does invite a skewed response, but my defense is that the people
I contacted are all quite capable of recognizing a red herring when they see
one. You'll see.

Opinions on Art and Programming

Someone I didn't attempt to contact but whose words live on is Albert
Einstein. Here are a couple of relevant quotes:

[W]e do science when we reconstruct in the language of logic what
we have seen and experienced. We do art when we communicate through forms whose
connections are not accessible to the conscious mind yet we intuitively
recognise them as something meaningful.

Also:

After a certain level of technological skill is achieved, science
and art tend to coalesce in aesthetic plasticity and form. The greater
scientists are artists as well.[1]

This is a lofty place to start. Here's Fred Brooks with a more direct look
at the subject:

The programmer, like the poet, works only slightly removed from
pure thought-stuff. He builds his castles in the air, from air, creating by
exertion of the imagination. Few media of creation are so flexible, so easy to
polish and rework, so readily capable of realizing grand conceptual
structures.[2]

He doesn't say it's art, but it sure sounds a lot like it.

In that vein, Andy Hunt from the Pragmatic Programmers says:

It is absolutely an art. No question about it. Check out this
quote from the Marines:

An even greater part of the conduct of war falls under the realm of
art, which is the employment of creative or intuitive skills. Art includes the
creative, situational application of scientific knowledge through judgment and
experience, and so the art of war subsumes the science of war. The art of war
requires the intuitive ability to grasp the essence of a unique military
situation and the creative ability to devise a practical solution.

Sounds like a similar situation to software development to me.

There are other similarities between programming and artists, see my essay
at Art In
Programming (PDF).

I could go on for hours about the topic...

Guido van Rossum, the creator of Python, has stronger alliances to Knuth's
definition:

I'm with Knuth's definition (or use) of the word art.

To me, it relates strongly to creativity, which is very important
for my line of work.

If there was no art in it, it wouldn't be any fun, and then I wouldn't still
be doing it after 30 years.

Bjarne Stroustrup, the creator of C++, is also more like Knuth in refining
his definition of art:

When done right, art and craft blends seamlessly. That's the
view of several schools of design, though of course not the view of people into
"art as provocation".

Define "craft"; define "art". The crafts and arts that I appreciate blend
seamlessly into each other so that there is no dilemma.

So far, these views are very top-down. What happens when you change the
viewpoint? Paul Graham, programmer and author of Hackers and
Painters, responded that he'd written quite a bit on the subject and to
feel free to grab something. This was my choice:

I've found that the best sources of ideas are not the other
fields that have the word "computer" in their names, but the other fields
inhabited by makers. Painting has been a much richer source of ideas than the
theory of computation.

For example, I was taught in college that one ought to figure out a program
completely on paper before even going near a computer. I found that I did not
program this way. I found that I liked to program sitting in front of a
computer, not a piece of paper. Worse still, instead of patiently writing out a
complete program and assuring myself it was correct, I tended to just spew out
code that was hopelessly broken, and gradually beat it into shape. Debugging, I
was taught, was a kind of final pass where you caught typos and oversights. The
way I worked, it seemed like programming consisted of debugging.

For a long time I felt bad about this, just as I once felt bad that I didn't
hold my pencil the way they taught me to in elementary school. If I had only
looked over at the other makers, the painters or the architects, I would have
realized that there was a name for what I was doing: sketching. As far as I can
tell, the way they taught me to program in college was all wrong. You should
figure out programs as you're writing them, just as writers and painters and
architects do.[3]

Paul goes on to talk about the implications for software design and the joys
of dynamic typing, which allows you to stay looser later.

Now, we're right down to the code. This is what Richard Stallman, founder
of the GNU Project and the Free Software Foundation, has to say (throwing in a
geek joke for good measure):

I would describe programming as a craft, which is a kind of art,
but not a fine art. Craft means making useful objects with perhaps decorative
touches. Fine art means making things purely for their beauty.

Programming in general is not fine art, but some entries in the obfuscated C
contest may qualify. I saw one that could be read as a story in English or as
a C program. For the English reading one had to ignore punctuation--for
instance, the name Charlotte might appear as char *lotte.

(Once I was eating in Legal Sea Food and ordered arctic char. When it
arrived, I looked for a signature, saw none, and complained to my friends,
"This is an unsigned char. I wanted a signed char!" I would have complained
to the waiter if I had thought he'd get the joke.)

Erik de Castro Lopo, coauthor of C for Linux Programming in 21
Days and also developer of the much used Linux audio library libsndfile,
had another take:

What I consider "art" often comes from a place that even the
artist can't fully explain. It breaks the boundaries of convention and
juxtaposes otherwise conflicting elements. It has an element of surprise. Art
is so often open to the interpretation of the viewer.

Programming OTOH is tightly restrained by what our programming languages
actually allow us to do. Our programs are also constrained by what we want them
to do; when they do something else we usually consider it a bug. When
programmers work with other programmers we are bound strongly by convention;
coding standards, documentation standards and so on.

Programming is definitely a craft requiring high levels of skill, but IMO it
is not art.

Martin Banks's Angry Old Man column titled "Artist or Artisan?" seems
to make a similar point, in the following quote:

And yes, that is hardly the world inhabited by anyone worthy of
the title of "artist", where creativity and making new 'rules' by breaking the
old ones is a stock-in-trade approach. So it would appear that the artist in
applications development has to die on the altar of process orthodoxy, or turn
into the artisan implementer of the orthodox. [4]

He goes on to say that in the cut-and-paste world of code components and
process orthodoxy, he still has hope. He has also used the word artist as a
description of the present.

Constraints and Art

The existence of so many restraints in the actual practice of code writing
makes it tempting to dismiss programming as art, but when you think about it,
people who create recognized art have constraints too. Writers, painters, and so on all have their code--writers must be comprehensible in some sort of way in
their chosen language. Musicians have tools of expression in scales,
harmonies, and timbres. Painters might seem to be free of this, but cultural
rules exist, as they do for the other categories. An artist can break rules in
an inspired way and receive the highest praise for it--but sometimes only after
they've been dead for a long time.

Program syntax and logic might seem to be more restrictive than these rules, which is why it is more inspiring to think as Fred Brooks did--in the heart
of the machine.

Perhaps it's more useful to look at the process. If there are ways in which
the concept of art could be useful, then maybe we'll find them there.

If we broadly take the process as consisting of idea, design, and
implementation, it's clear that even if we don't accept that implementation is
art, there is plenty of scope in the first two stages, and there's certainly
scope in the combination. Thinking about it a little more also highlights the
reductio ad absurdum of looking at any art in this way, where sculpture becomes
the mere act of chiseling stone or painting is the application of paint to a
surface.

Looking at the process immediately focuses on the different situations of
the lone hacker or small team as opposed to large corporate teams, who in some
cases send specification documents to people they don't even know in other
countries. The latter groups hope that they've specified things in such detail
that they need to know nothing about the code writers other than the fact that
they can deliver.

The process for the lone hacker or small team might be almost unrecognizable
as a process to an outsider--a process like that described by Paul Graham,
where writing the code itself alters and shapes an idea and its design. The
design stage is implicit and ongoing. If there is art in idea and design, then
this is kneaded through the dough of the project like a special magic
ingredient--the seamless combination that Bjarne Stroustrup mentioned. In
less mystical terms, the process from beginning to end has strong degrees of
integrity.

The situation with larger project groups is more difficult. More people
means more time constraints on communication, just because the sums are bigger.
There is an immediate tendency for the existence of more rules and a
concomitant tendency for thinking inside the box. You can't actually order
people to be creative and brilliant. You can only make the environment where
it's more likely and hope for the best. Xerox PARC and Bell Labs are two good
examples of that.

The real question is how to be inspired for the small team, and additionally,
how not to stop inspiration for the larger team. This is a question of
personal development. Creative thinking requires knowledge outside of the usual
and ordinary, and the freedom and imagination to roam.

Why It Matters

What's the prize? What's the point? At the micro level, it's an idea
(which might not be a Wow idea) with a brilliant execution. At the macro level, it's a Wow idea (getting away from analogues, getting away from clones--something entirely new) brilliantly executed.

I realize now that I should have also asked my responders, if they
were sympathetic to the idea of programming as art, to nominate some examples.
I'll do that myself. Maybe you'd like to nominate some more? I think of the
early computer game Elite, made by a team of two, which extended the whole
idea of games both graphically and in game play. There are the first
spreadsheets VisiCalc and Lotus 1-2-3 for the elegance of the first concept even
if you didn't want to use one. Even though I don't use it anymore, the C
language is artistic for the elegance of its basic building blocks, which can be
assembled to do almost anything.