Code and Art
People talk about beautiful code. They say that code is poetry. But what does that mean? Where does the aesthetic lie in good code? Can code ever be art?
Code and poetry
The WordPress.org website still boasts that code is poetry in the footer of every one of its many pages. It’s a tempting proposition. Martin Amis once wrote in a review that the only resemblance between poetry and the author’s work was that her lines did not reach all the way across the page. That’s often true of code – especially code that follows the style guides of most modern languages. So, for a start, code often looks like poetry.
There is more. Beautiful code resembles poetry in some other key ways. We value economy, for example. We strike down redundant clauses. We factor out needless repetition. We look for balance and clarity.
Still, anyone who has followed a shopping list knows that short lines do not make a poem. There is nothing stopping you from writing a poem in code (just as the shopping list poem is up there with the day in the life of a coin as a school exercise). But if you did so, it would be a poem because it was written to reach beyond code, and not because it was written with code at its core.
On the whole, code does not concern itself with rhyme, rhythm or metre. Clean code is aesthetically pleasing, but it does not set its form into a complex relationships with its subject. Read aloud, it does not, for example, evoke the validation of a user account in anything like the way a poem about a train might mimic the sound of wheels on a track.
While beautiful code aspires to clarity, poetry lives in a more ambiguous space. It plays mysterious games with meaning. A short well-formed function will tell you exactly what it is going to do. It should therefore aspire to utter clarity. A haiku may be equally as sparse – more so – but in all likelihood there’s more going on in those few lines than the snow on that cherry tree and the memory of spring blossom. A haiku may be haunted by loss or hope, it may mean several things at once. It is sly and mysterious. This shadow world is something that, by default, code attempts to strip away.
Code attempts to fix meaning. That’s the mission of good code, anyway. A poem offers agency to its readers so that meaning can be renegotiated whilst the poem still retains something of its animating essence. That is why we still read Homer and endlessly revisit Shakespeare.
It is unlikely we will port lines of code from Fortran to Python in order to conjure a sense of the beauty they possessed in a language that few now use, though we might do so in order to retain their utility.
Still, if beautiful code is not poetry, it still shares a fair amount. Good code has a lightness to it. It balances efficiency with clarity, it demonstrates its cleverness without boasting. Reading good code is a small pleasure.
Code and craft
Perhaps then it’s better to think of code as craft. We fashion programs the same way that a carpenter fashions a chair or a table. This is more promising, maybe. After all, there’s plenty of room for art in craft.
This feels right. And the idea of coding as a craft certainly has a following. I’m not going argue against it here, either. There is instinct as well as precision in coding, after all. Coding well requires balance. One must know one’s tools, understand the trade offs involved in any choice. One must take pride in the work. These are all characteristics of the craftsperson.
So the act of coding suggests the verb to craft. But what about the product? In creating a chair, a carpenter builds just that. A beautiful and useful object. A programmer creates a product certainly, but where does its aesthetic value lie? Is the code a work of art, or is the running product the site of value?
That might seem a stupid question. But remember, we started with the question about code and poetry. We took the proposition that code is poetry seriously, at least to some extent. In that formulation, the aesthetic would lie in code as communication rather than in the product that the lines of code were written to animate.
Code as communication
The craft of programming resolves to an end product – an app or a library. But we also generate an aesthetic in the code we produce.
The target of a line of code is a computer, via a compiler or an interpreter. A script is a set of instructions for that computer.
Except that we also write code for one another. Code is reviewed. It is weighed. It is read and amended. Code is written for our future selves. Sometimes the readability of code – by which we might mean its elegance even its beauty – outweighs its efficiency.
High level computer languages have fierce adherents. Sometimes this loyalty is based on logic. More often, perhaps, the loyalty is based on what feels familiar, in the common cause we feel for our colleagues. But it’s also often a matter of what makes aesthetic sense. Our support for a language can be based on perceptions of elegance – even beauty.
Almost without exception, programming languages lean on written or spoken general languages. The statements of computer languages resemble sentences.
The syntax of a modern computer language is subset of human language. It is human language. As such the meanings we take from it are more nuanced and mysterious than the meanings that are targeted at the processor that runs the code.
So if code is not poetry, it is perhaps at least not not poetry.
Code and mimesis
In looking at what we generate as programmers we have, so far, focused on the lines of code themselves. But if programming is human language, it means we generate something much more complicated than just instructions. We generate mental models. Which is to say, we generate fiction.
One version of this that’s tempting but deceptive is the idea that code models the world in a mechanistic way. Object-oriented programming is the siren here.
Many coders learn to create classes and objects using Car and Person and Contract archetypes. We often deploy our world analogue classes within the MVC – Model View Controller – pattern. The correspondence between a set of classes and their real world counterparts is a crude one but it can be compelling.
It suggests a software analogue to the theory of forms, Plato’s idea that a realm of essences exists outside of the perceptible world. After all, the theory of forms suggests a kind of cosmic class diagram in which essential thingnesses exist as the ultimate superclasses.
Of course, the theory of forms is not itself terribly coherent and the correspondence between class hierarchies and the material world breaks down pretty fast. The world does not make a good structure for a program and, as you bend your code to utility, you wrench it away from mimesis pretty quickly. Even if you manage to keep domain logic from your Person and Location and Book objects they will inevitably owe more to the utility of your project than they will to personhood or the characteristics of place and books.
Still, it’s pleasant to imagine a realm in which the archetypal form of table towers over the material world alongside the abstract supertypes of Contract and User.
So the models we create with code do not themselves describe the world. Of course we could create programs which do that – but that is an outcome – at the level of calculators and browsers and games.
Code and its interface
As an aside, for the purposes of this article, code is orthogonal to its uses. In other words, ugly code can power beautiful interfaces and vice versa. Good code can be put to bad ends.
By all accounts, for example, a section of pleasingly clear code represents a key piece of evidence in the prosecution of FTX for misusing funds.
Without taking a position on it here, it’s also worth noting that WordPress – the populariser of the Code is Poetry slogan – is itself often criticised for some pretty ropy source code despite the fact that it powers many undeniably lovely websites.
Code and the invisible machine
Here, personally, is where I find one of the most aesthetically pleasing aspects of code. And, oddly, it is one which, almost by definition, cannot be seen.
Think of a class diagram representing the participants of a system. Now think of a sequence diagram which shows the interactions of those participants through time. Now imagine the components running. Conjure a machine or a factory with its inputs and outputs. Zoom out from the program described by your diagrams to the wider world of those inputs and outputs, a whole universe of other machines, and beyond them, perhaps, people.
The machine you have imagined has extent. It is a kind of thing in a kind of place. And yet, you can’t see it. The class and sequence diagrams describe it. You can see evidence of its behaviour in its interfaces and through by-products in logs and databases. You can see the processes on running on the computer. You can monitor memory. You can watch Grafana churn visualise stats galore. But you cannot actually see the machine.
If you design your code well, using a vocabulary that other programmers understand and code which points the way, they will also be able to imagine the machine.
In some ways, this makes the labour of coding a little like that of working in the eaves of a cathedral a thousand years ago. The Medieval craftsmen and artists who laboured beyond the eyes of priests and congregations might have had the consolation that God – and perhaps an entire audience of saints and angels – would perceive and appreciate the work. A modern secular coder can only have faith in a shared leap of imagination. A common imagined realm.
Code and the story world
Code is communication. It is a set of instructions for a computer. But in one of its aspects it is also a set of instructions for imagining a machine.
A written story is a set of instructions. It is a set of instructions for imagining a world over time. Start here, it says, this is the world. Now bring this character onto the stage. Listen. This is what happens next. The world of the story cannot be seen. No-one has actually seen the Middle Earth or Middlemarch described on the page. But, as readers, we collaborate with each other, with the writer, to use these instructions and we make something real of made up places and people and events.
The imagined invisible machines we create as programmers are our story worlds. Are they art? They are probably closer to the items of furniture made by craftspeople – but like a Shaker chair, or Bauhaus lamp, the machine can be beautiful. In this version of the aesthetic, the lines of code may be pleasing in themselves – but in their clarity they serve the greater aesthetic of the systems they are written to share.
If you liked this diary entry or anything about this site and its projects you can help us out by spreading the word. You can also sign up to join the Hidden Hat mailing list.
Thanks for reading. Next time: a check in on progress.
Photo by Alexander Grey on Unsplash
