Article: 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:

We 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.
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.

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.

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.

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.

Anyway, go make some art. Why not?!