NO! Programming as Other

A year ago I was reading the CfP for HAPOP 2020, the 5th symposium on the History and Philosophy of Programming, and there it was again, the quasi-philosophical question that keeps haunting our industry. In fact, it was listed as the very first question in a long list of potential questions of relevance for the conference:

Can/has been/should be programming understood as an art, a craft and/or a science?

Which is admittedly a strange version of the question, as it doesn’t quite parse and also contains several permutations of the basic question written as a single question. It kind of makes you suspect that it was written by a programmer. But it’s still fundamentally the same question:

Is programming art or science?

And my immediate reaction was: Et tu, Brute? Even you, HAPOP?

And my second response was just NO! I reject the question! I hate it! And I didn’t necessarily know why, but I knew very well that I did, and so I quickly wrote an incoherent rant in my TiddlyWiki to get it out of my system. And then nothing much happened for a year. Until now, in fact. This blog post is an attempt to write down a more coherent version of that rant. It is an attempt to perform a little introspection and try to explain my own reaction to myself. What is it about this question that annoys me so much? What’s wrong with it? Where does the anger come from?

Let’s start by considering the question as a meme. Memetics is the idea that memes – ideas or soundbites – are like genes in that they replicate, mutate and compete for attention.

When discussing a particular meme, an interesting question is how valuable it is. What is it worth? One way you might measure the value of a meme is by looking at the output it generates – the sum of the insights and new ideas it produces over time. And I’m frankly very, very disappointed by the output generated by the question “is programming art or science?”.

From what I can tell, the original “is programming art or science?” article is Knuth’s 1974 ACM Turing Award lecture “Computer programming as an art“. If you read that lecture, and compare it to whatever people have been writing about the topic since then – at least the writings I’ve found – you’ll find practically no new insights. None! Instead you’ll find poor echoes, and echoes of echoes, of what Knuth tried to say in 1974. That’s a terrible track record for an idea: close to 50 years of stagnation, of rehashing the same stale points over and over. And yet we continue to treat that question with reverence, as if it were somehow an important question, one that is worthwhile to keep asking.

It’s a shame that memes don’t compete by the usefulness of their output. But alas, for a meme to be reproductive, it just needs to make the host feel good, and a good way to do that is to appeal to our vanity. And it just so happens that merely asking the question “is programming art or science?” makes us feel sophisticated and philosophical, we can sip a little wine, gaze into the horizon and nod as we contemplate and admire the depth of our own souls.

It’s also useful for a meme to create a sense of community, of recognition and belonging – a sort of in-code for members of a club. One of the things that unite us as programmers is that we are constantly discussing if we’re doing art or science. And the answer that we have all memorized (yet at intervals feel the need to repeat to each other), is this: “it is neither and both and isn’t it grand”. And if you get really worked up about that answer, you write a blog post. Such blog posts invariably approach the question in a slightly roundabout fashion, which involves a Google search for more or less arbitrary definitions of art and science that fit your purpose, and then meandering a bit back and forth before concluding with what was already known. And again, that pattern was laid down by Knuth in 1974. Nothing new there.

That silly little dance is probably what annoys me the most about the question. It is as a form of pseudo-intellectual posturing and peacockery. It’s just show, there is no substance to it. It’s very very easy to do. It requires no original thinking. While dressing up as somehow intellectual, it really represents the opposite: mindless parroting.

And it’s not without cost. After all, memes do compete for attention and replication, and if we’re constantly asking the same old question (which generates no new output, no new insights into what programming is or isn’t) then we’re wasting precious meme space. We should free up that space to ask different questions. There’s an opportunity cost to asking unproductive questions over and over again, as if they were interesting. The unproductive questions occupy brain real estate that could be used for something productive instead. Hence we need new questions, questions that will stimulate actual intellectual effort.

So much for memes. Another perspective has to do with linguistics, or at least it seems that way to me, a non-linguist. If we are to take the question “is programming art or science?” seriously, we should start by taking a close look at what we mean by the words we use. For instance, we’re not very explicit about what we mean when we use the word “is”.

Consider a sentence like “programming is art”. What is the significance of such a sentence? What could it mean? Do we mean it descriptively, as a statement of fact – I think programming is art in an objective sense – or do we mean it normatively, as something that we wish were so – I think programming should be art, programming would be better if it were art. We can’t possibly mean that programming actually equals art. They’re not synonyms. There must be some other relationship between the words. Presumably it’s more about readings or perspectives than about identity. We’re perhaps trying to paint the meaning of the word “programming” by applying the paint of other words, which seems to be the way language works.

In reflection of that, let’s see what happens when we substitute the word “as” for “is”. It seems to be closer to what we’re actually trying to accomplish. We can ask, for instance, what happens if we consider programming as art, what insights might follow from that. (And to be fair to Knuth, that was actually the title of his 1974 lecture: Computer programming as an art. He didn’t say that programming was art, he said that programming could be and perhaps should be viewed as art.) Or we can ask, what happens if we consider programming as science, what insights might follow from that?

But we never seem to do that. We always discuss programming as art and as science at the same time, together. They’re tied together, and for that reason we never delve very deeply in either of the perspectives. Why is that? Why is the comparison more important than the perspectives by themselves? I think it’s because we’re really using art and science as metaphors. Art isn’t just art, it is a symbol for creativity, gut feeling, the humane. Similarly, science represents cool reason, logic, the mechanical. When we’re asking (over and over!) if programming is art or science, art and science act as metaphors for these perceived opposing forces. Sometimes, we substitute “craft” for “art” or “engineering” for “science”, but the metaphorical battle between the elemental forces remains the same.

One might expect that such an exercise would be fruitful, that it would produce useful output. There is something to be said about using two more or less opposing perspectives to describe something. But at the same time, Knuth has already done that exercise for us, and apparently we don’t have much more to say. If we did, we should have done so by now. Moreover, viewing art only in contrast to science and science only in contrast to art is also very limiting. It holds us back from going very far in our consideration of programming as either art or science.

For instance, let’s go back to the reading of programming as art. Such a perspective could be greatly expanded upon, but it’s unlikely that it will happen as long as it is forever joined at the hip to that other question. If art is always considered in contrast to science, then we won’t ever delve very deeply into the notion of programming as art as such. But we could. We could take the perspective programming as art seriously, and we might even discover something interesting, or at least be saying something that hasn’t been said a million times before. Even without much thinking, it is very easy to sketch some basic questions that still never come up in these endless repetitions of the art-vs-science meme.

If we consider programming as art, what is the artwork? To Knuth, the answer is the source code, the “listing” as they called it back then, presumably because you had it printed out, and could treat it as a physical artifact. And it’s both interesting and peculiar to think of it that way. Transposed to the world of music, it’s like considering the sheet of music to be the artwork rather than the actual music you hear. Moreover, since no-one has expanded much on anything in Knuth’s original article, that’s the only perspective I’ve seen, which is quite startling. It’s certainly not the only possible answer. The ontological status of programs is actually very interesting. What is the program? Can we really ignore what happens at runtime, the execution or performance of the program if you like? Is what happens at runtime implicit and somehow baked into the source code? Is the program the sum of all possible executions of the program? All actual executions? Are the partial simulated executions inside a programmer’s head included as well, including erroneous ones? What about self-modifying programs? Or a program’s evolution over time in general?

Who is the artist? In Knuth’s time, it seems, it was assumed that there was a single author for programs, and so a single artist for the artwork. But much if not most programming today is collaborative. Does the artist matter? Is the artist interesting? What about mob programming?

What about the experience of art? Obviously that’s going to be related to what the artwork is, the nature of the artful artifact. Is it tangible? Visible? Decipherable? To whom? Who is the audience? Can only programmers experience programming as art? Come to think of it, where are the exhibitions, and what are they like? If programming can be seen as art, can be artful, surely there must be art exhibitions, where we can appreciate the art of programming? Is it GitHub?

I guess you could argue that the demoscene arranges exhibitions of the art of programming. But I don’t think most programmers think of the demoscene when they talk about programming as art. Maybe they’ll mention it when pushed by someone asking annoying questions, but my impression is that it’s mostly about the sentiment that “code can be beautiful”. Which is fine, but not very profound. It also implies a very limited and antiquated notion of art. Modern art is often unconcerned with beauty or meaning in a conventional sense. (What is the aesthetic of programs? When is a program kitsch?)

Those are just a few of the questions that can be asked to delve at least a little deeper into the reading of programming as art. And we could do the same for programming as science.

A more pressing issue is: why on earth would we stop at just those two? It seems to me that we suffer from extreme lack of imagination if those are the only two readings of programming that we can give, and that we are somehow condemned to repeat those two readings forever, in tandem. It’s like you could never analyze Hamlet from anything else than a Freudian angle, as an Oedipus drama. I think we desperately need to break out and look at other perspectives. What is programming as neither art nor science? What is it then?

What happens if we think of programming as something else entirely, or even as the negation or absence of something? Are there aspects of programming that somehow escape our attempts to capture or describe them with metaphors? What is the irreducible other of programming?

Eventually we might ask ourselves – as we perform these readings, these attempts to highlight some aspect of what programming might be – what is the purpose of this exercise? Why are we doing it?

That might seem silly, because surely we do it to understand programming better, right? It’s an act of interpretation aimed at answering the question “what is programming?”.

But that’s not the only possible explanation. Another way to look at it is that we are reading – interpreting – programming to be something ourselves. Because programming is something that we, programmers, do. Whatever programming is determines who or what we are. Programming makes the programmer. Whatever metaphor we apply acts a mirror, and we want to like what we see in the mirror.

For instance, viewing programming as art makes the programmer an artist. This is clearly a desirable identity for some, with Paul Graham being the most prominent example. Unfortunately, borrowed clothes often fit poorly, and borrowed identities are often hollow. You risk that someone will call your bluff. Programmers are first and foremost programmers. And why shouldn’t that be enough? I am curious as to where this impulse to borrow legitimacy and status from other identities comes from. Why aren’t we content to be mere programmers? Why do we feel the need to borrow feathers from others?

To summarize then: “is programming art or science?” is a stale meme that generates little insight. It is as much about crafting an interesting identity for ourselves as it is about programming as such. If we truly want to understand the nature of programming better or our own identities as programmers better, we should focus on more specific, more direct, more honest questions. There is no shortage of such questions if we are prepared to make a little effort. But the more to the point the questions are, the less room there is for bluffing.

---