Art and Computer Programming

Listen Print Discuss

Art and Computer Programming

by John Littler
06/30/2005

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.

Anyway, go make some art. Why not?!

References

[1] from Alice Calaprice, The New Quotable Einstein, Princeton.

[2] Frederick P. Brooks, Jr., The Mythical Man Month: Essays on Software Engineering, Addison-Wesley, Reading, MA, anniversary edition 1995.

[3] http://www.paulgraham.com/hp.html is an essay that's part of Hackers and Painters, published by O'Reilly.

[4] p. 50, Application Development Advisor, May/June 2005.

John Littler is chief gopher for Mstation.org.

Return to ONLamp.com.

What's your take?
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 14 of 14.

Art and Programming
2005-08-13 13:36:27 knowingart.com [Reply | View]

One of the challenges of Art is that you are starting with a blank piece of paper or canvas. In the case of the canvas, most serious artists build them from scratch--they cut the wood, glue, sand, stretch, staple, etc. etc. Until recently even, artists needed to be chemists also and they would produce their own colors. Where I can see the comparison between Art and Programming failing is when a programmer is using a high level language or using an API or for example Ruby on Rails. If you really want to call yourself a software "artist", you should go back to the old traditions--draw your own fonts, draw your own "windows"... In fact you should question these very concepts--what is a font--what is a window? Back in the 1980's trying new software was more enjoyable because you were always surprised--each program had its own look and feel--a unique interface, a unique approach... Once Windows 3.1 came out, most applications lost their originality--everything was uniform, predictable--the goal was productivity and financial gain.

Also, Art in an ideal sense is not motivated by financial gain--the "starving artist" scenario is a function of humility. Picasso had a huge ego but I would argue that we are attracted to these paintings because he is so honest in saying (or pretending) just how important he thinks he is. Art has no practical, worldly application--otherwise it would not be beautiful. Just the fact that we call most programs "applications" tells you something. The original "Game of Life" might be an example of a program that wasn't coded as an application--it was more of a curiousity (read the book "Hackers"). As we know, beauty is easily spoiled by motives. If you found out that your girlfriend was after something materialistic, how beautiful would she be then? Beauty that asks for favors or accolades or profit is no longer beautiful and not to be trusted...a farce without merit. So in summary, Art comes out of ideals: honesty, love, etc... Programming on the other hand is more about productivity, efficiency, utility, profits, personal gain, etc. If you were locked in a room with no paint brushes and only a PC and you wanted to make some art--you would better off destroying it--then take all the little pieces and make something entirely new :)

(programming(computers) == *art) ? so : what
2005-07-17 14:23:06 saschabrossmann [Reply | View]

i just don't get it. this debate has been surfacing every now and then since decades and each time seems to miss the very obvious (to my eyes, that is): it confuses means with their respective ends and accordingly leads to: nowhere. let's face it: the question whether programming is similar to art is not decidable on the grounds on which it is commonly discussed: those are incomparable categories.

you might use programming for works of art, you might use programming for works of design and engineering and you might use programming just to entertain yourself and have a good time and many things more. and in that very way it is comparable to painting, to sketching, to writing, to welding or whatever craft is appropriate for the desired outcome. yes, craft. nothing to be ashamed of.

and if you still want to compare, please start comparing purposes.

Art lies in the eyes of the programmer
2005-07-08 09:03:03 Phoenix_S [Reply | View]

We can write the same application in many different ways, using many different designs. When I write a function that has a single return statement instead of multiple points of return, it gives me a certain pleasure (even if it has the same result as its multiple return points counterpart).
A nice design that comes to mind when writing an application, can it not be compared to a painting that comes to a painter or a symphony to a musician from some unknown place?
The more we are in contact to that unknown place, the more developed our consciousness is, the more beautiful programs we can write!
-Sid.

Good write but...
2005-07-07 07:54:47 leopoldog [Reply | View]

for me the programming is an art and is not an art.

Why?

Simply because the programming is only a tool used to make something. Is like asking if stone-working is an art or a craft.

Take the Cathedral builders of the middle age, it was an art or a craft or something other?

For the architect perspective building a cathedral is sure an art, for the simple worker that cut the rocks and put it together to build the building is a work like any other, it requires skills, but is not an art. In this case cutting rocks is not an art.

If the same rocks where cut by a sculptor, the same rocks-cutting process belongs to the art, and is not a simple rocks worker.

The point is that is not "cutting a rock" that can be called art, is why whe are cutting the rock.

The architect that build the cathedral and the sculptor have a common point, both imagines something and realizes it with some work. The architech delegates the hard work to workers (that are tools for his point of view) and the sculptor make the work itself, but the point is that we begins with an idea and concludes with something "solid".

Programming is similar, a big industry's engineer is like the architect, he imagine a system and then use tools (the programmers and the computers) to realize. An independent programmer make all this work by itself, is more like the sculptor.

In this case the artists are the engineer of the big industry and the independent programmer, and the tools are the workers and the computers.

In both cases we have expressions of art and craft.

At the same time a simple programmer in the big industry can be an artist by itself, but for other programs.

Both aspects are present and we cannot reduce the talk to the simple question "is art or not", the answer can be only one "programming is both art and craft".

Really?!
2005-07-07 06:54:05 molly6 [Reply | View]

i. how about "the art of conversation" or "the art of cooking?"

ii. the "art" term is used here in the sense of "excellence". Practically any profession qualifies.

iii. true "arts" are just 7. they all have in common something called "transcendental". can cooking be transcendental?

iv. is this offending for us, the programmers? on the contrary, this is good news since true artists have a tendency to die poor…

Is Programming Art?
2005-07-06 22:58:39 rwalling [Reply | View]

For more discussion on this topic, visit: http://www.softwarebyrob.com/archive/2005/07/06/Is_Programming_Art.aspx

No study done on the counterpoint
2005-07-06 10:55:48 frogooa [Reply | View]

Just like a good software test should attempt to break the software, a good stance requires the refutation of the counter argument.

This editorial is lacking that, so it comes off as more faith than fact.

Medium vs Message
2005-07-06 06:30:03 nurbles [Reply | View]

The article and many of the comments seem to be trying to consider where programming is an art by examining coding. IMHO, that is no more valid than examining typing (or handwriting) to determine if a novellist is an artist or examining hammers and chisels to decide is sculptors are artists.
The code is a tool the way that information is accessed, manipulated and presented is the art that a programmer produces. Combining existing ideas in new ways (and creating completely new ideas) to make some chunk on information more useful (or whatever aesthetic pleases you) is what makes programming art.

Well of course it's art
2005-07-06 05:33:56 kbw333 [Reply | View]

In recent years it has been said that art is something produced by an artist. This goes on to imply that if you're not an artist, your products cannot be seriously considered art. It justifies an artist's messy room as art, and everyone else's as a messy room. This point of view is also used to justify the publicity awarded to particular popular artists, while keeping the lid on others. Occasionally, as if by osmosis, an new artist will be discovered and he/she'll join the ranks of established artists.

When I was younger, there was talk of Arts and Crafts. These days it's the arts that get focus and there's little talk of craft. Craft seems to be implied in art. For example, a clever photograph will often require skill with a camera and until recently, with film processing. This is an example of arts and crafts being bound together. These huge metal sculptures I keep bumping into are clearly art, but require knowledge of metal working to achieve them; again arts and crafts. I don't think you can have one without the other, it's a matter of emphasis.

It is said that the most complex structures built by mankind are software systems. This is not generally appreciated because most people cannot see them. Maybe that's a good thing because if we saw them as buildings, we'd deem many of them unsafe. But this obscurity leads to a generally unrecognising of the beauty of some software.

It is clear that software construction is a craft. But you just need to try it to realise that it's art too. The whole idea of design patterns was an attempt to elevate the art in novices. There are many ways to construct software, but it's artistic input that makes it manageable, beautiful, and reliable.

A good overview.
2005-07-06 01:05:15 aixguru1 [Reply | View]

Constraints are found in any type of art. For instance with painters, your canvas is a set size and your brushes are the ones (random things included) that you have nearby. You have a limited set of tools and constraints, but still the world is open to you.

The same is true with programming. You have constraints, but as Brooks say, "air from air". You can imagine, create, and manipulate your programs to do whatever you want them to do.

One thing to note on another comment I noticed was a comparison of craft and true art based on skill levels. As with artists, programmers come with various degrees of skill. Some art is primitive and unskilled, but practice makes perfect and a programmer that works on his skillset can improve as well.

One argument is that programming is structured and follows after others. The key is that art is the same. Look up figure drawing for example and you will find the techniques most artists use for basic figure drawing to create what later become works of art. Art also immitates nature and other artists in many cases. Sometimes immitation is the highest form of flattery. With programming, imitation is a key to success on various levels. For instance, I personally referenced and learned many things about coding from the Richard Stevens books and his examples. Many others have gained knowledge on "best practices" in coding as a basis to help them create. Much like the eliptical shapes, ovals, circles, and other shapes that make the lightly drawn poses in the start of a figure drawing, programming has those key APIs, bits of code, libraries, classes and "shapes" if you will that help you create the final "picture" that makes up what we call our art.

The art of a programmer.

art vs. craft
2005-07-05 23:06:02 unwesen [Reply | View]

being a programmer myself, and working closely with artists, i have found that programming and writing/painting/composing music are rather similar activities. one of my artist friends in particular was interested in what programming actually is, so we struggled to find a definition for it.

as it turns out, we quickly accepted that programming must be craft.

we agreed that in order to be a reasonable artist, one has to be a good artisan. art that isn't executed well is a stroke of luck, might be beautiful, but is essentially meaningless. an artisan who puts thought and experience into the piece he creates, however, creates a manifestation his thoughts, and thereby makes them accessible to others. craft, in other words, is a carrier medium for culture. we judge long-dead cultures by the the 'things' they have made. it is no accident that we call these things 'artifacts', from the latin words 'ars' (art) and 'facere' (to make, to create).

if the products of craft are carriers of culture, what, then, is art? it's something you might call _inspired_ craft. again, if you look at the latin roots for 'inspiration', 'spirare' means to 'breathe'; receiving an 'inspiration' therefore is receiving the breath of life, the spirit that god reputedly breathed into us in order to make us alife. creating life is universially seen as creating something new - in the simplest sense, children are 'new' human beings.

art, therefore, must be craft that has an element of newness to it. how do you achieve something new? by breaking the boundaries of the system within which everything 'old' exists. if craft is a carrier for our culture, art by definition must break with that culture. now there are two possibilities: either your art is rejected by the majority of people, or it is accepted as beautiful. in the first case, it might be anything - meaningless, ahead of its time, etc. in the second case, however, it will quickly become part of the culture it broke with - culture expands to embrace those slight deviations from its norm.

art, therefore, is craft that advances our culture. in this i differ strongly from stallman's opinion that art is 'merely beautiful' - it must have an impact on our culture in order to be considered art. that might sound rather elitist, i'm afraid... yet consider that every culture contains subcultures, and the impact i'm speaking of does not have to be earth-shattering. a street musician known in one part of a smaller city for his inspired music is an artist, even if his art reaches a few hundred people at most. as long as it's not a mere reproduction of our culture, it's art.

reading through all this again, i still agree that programming is mainly craft. if you are an inspired programmer, however, you might well create art. as with conventional artists, whether your creation is art or craft may sometimes not be recognized until long after the act of creation.

i could go on about this. i know there are some aspects still not covered, but this text is too long already. in closing i would like to use this text as an example of art vs. craft. i certainly know how to write, and to some extent how to phrase my thoughts in order to acheive certain effects. in that sense, i'm an artisan (although, admittedly, not a very good one). whether this text can be considered art depends very much on the readership: either i have restated the obvious, then it's merely poor craft. if i have managed to blow fresh thoughts into enough of your minds, it might be considered a small work of art.

Indeed it's art
2005-07-05 20:41:12 tonywilliams [Reply | View]

I, too, program like Paul Graham. Most of the great programmers from whom I have learnt program exactly the same way - they just pproduce better code on the first pass than I do (g).

A nomination for art I've seen? Unix design was an example of art. The power of "everything is a file" and the concept of a pipe are pure art. I have recently been reading the O'Reilly title "Classic Shell Scripting" and it has examples of combining those two principles to produce amazing software - such as a spell checker in a single pipe.

Rael Dornfest's original version of Blosxom was art. Blog software in a very small number of lines of Perl that used simplicity, the power of Perl and the facilities of the underlying OS. Since then the refinements and improvements have been like the final polish of a sculpture.

# Tony

I program like Paul Graham!
2005-07-05 16:32:53 makeme [Reply | View]

TFA quotes Paul Graham as saying:

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

This is how I program! Maybe I'm not as crappy a programmer as I originally thought!