The Aesthetics of Code

I’ve been reading and thinking a lot lately about aesthetics and computing. More specifically, about the divide that exists between form and function in regards to computer code. There are two cultures at work, two views of the same thing, but vastly different. Take the programmer… He sees his job as requiring him to consider two points:

1) The usability, by non-programmers, of the software that he creates

2) How the software (code) is to be maintained by other programmers.

This generally evolves into a sort of reductive language, rather than a productive one. It ends up as a mathematical artifact that becomes embedded in the natural world. Originally, these were not really part of our natural world, because the only demand for computers and software was from the people who created and maintained them. There was no real link to the “normal” world of non-programmers.

But now we, as non-programmers, are beginning to hold opinions about the aesthetic aspects of the programmer’s work. But we’re still in flux, in a state of transition with it all, because for the most part, we still have no idea what the hell a programmer actually DOES. Code is still mysterious, still reserved for geeks, still an arcane, unknowable thing that works as if by magic. We never see it; we’re not concerned with it, any more than we’re concerned with what makes our cars run or our planes fly. We just use it, blindly and happily. Who cares what lurks inside? It plays music on our iGadgets; it streams YouTubes; it lets us text each other, follow each other on Facebook, call each other on Skype. Who cares? It just works. Somehow, all those odd sentences, those brackets and parentheses and semi-colons… well, somehow they just seem to make it all work, and for me that’s all that really matters. Isn’t it?

As McLuhan said, while we’re still focused upon the content of our new digital media, we will fail to recognize its very nature. We’re enamoured of the contents of our computer screen, but we fail to understand that it is the code behind it that creates the rules by which we are now living our lives.

2 thoughts on “The Aesthetics of Code

  1. I’ve always liked Wall’s comment on good programmers – they’ll go to remarkable efforts to avoid having to do something by hand! “All programmers are playwrights and all computers are lousy actors” is another (but note: playwrights writing in terse, foreign, persnickety languages).

    I try to impress on my students that the benefits of automation are not just the time and labour saving, it’s the reliability. A human is going to make mistakes, no matter how slowly and carefully they work. And of course that applies to programming as well! So, it can be arcane and frustrating to get it right, but when you do, you seriously reap the rewards.

    I’d say it’s magic to most programmers as well. For years, software developers have been so far removed from the hardware that it might as well not exist, and we keep striving for more and more abstraction. Few people can comprehend the workings of a modern CPU, let alone the entire stack that runs on it. And it’s still a huge challenge to (a) really pin down what you want the computer to do to solve your problem, and (b) communicate that to the computer in a way it can understand. As you say, the code and its results might as well exist in different dimensions. And if you care about performance, you still have to know a bit about how the hardware is going to execute the code (or whatever derivation of it eventuates from a modern compiler).

    I find the IOCCC (International Obfuscated C Code Competition) fascinating, because it takes the natural obscurity of code to playful extremes. Many of the entries have fun with the formatting of the code, creating ASCII art often hinting at its function. Some programs (quines) produce copies of themselves as output (and there are even quine cycles).

    There are languages that try to bridge that divide. Smalltalk is probably the best attempt I’ve seen – a truly integrated, explorable, visual, real-time development environment. There have been attempts to make programming more graphical – I quite like the Nassi-Schneiderman diagramming approach (sort of a “flowcharts-for-structured-programming”), but for problems that are fundamentally mathematical it’s hard to beat an expression that is mathematical in style. And not everyone (myself included) finds that an easy mode to think in.

  2. Larry Wall, the author of Perl, once wrote that the three essential character flaws of any good programmer were sloth, impatience and hubris. Good programmers want to do the minimum amount of work (sloth). They want their programs to run quickly (impatience). They take inordinate pride in what they have written (hubris).

Leave a Reply