April 23, 2013
MarkBernstein.org
 
Follow me on Twitter

Speaking Code: coding as aesthetic and political expression

by Geoff Cox and Alex McLean

Two distinct groups of people are interested in the aesthetics of computer programs. On the one hand, we have people who create software; those with taste and judgment will naturally hold aesthetic opinions and prefer the beautiful to the ugly. Opposed to these artisans, we sometimes meet a group of theoretically-inclined critics or "codewerkers" who compose things that look like poems but that ridicule the benighted corporate fools who make or use real software.

In Speaking Code: coding as aesthetic and political expression, Geoff Cox and Alex McLean are writing for the latter. The program code of which they speak is almost always either a hypothetical category too broad to be analyzed or a clever stunt ginned up in a dozen lines of perl. These toys are sometimes clever, but they have little to do with actual programs, and their creation has little to do with the construction of actual code. It is as if the authors set out to write about painting but, finding actual painters dead and actual paintings opaque, decide instead to analyze instead the movie actors who portrayed some painters. The actor’s version of Jackson Pollock might look like a painting, and it might be made from paint, but it’s not Pollock.

The book is filled with tiny little programs. Some of them run. Some of them simply look like programs and are meant to be read. The first example is written in an esoteric language called Befunge, and the general level of scholarship in this volume is reflected in the first footnote.

As an esoteric language, Befunge also breaks with the conventions of downward direction of interpretation through two-dimensional syntax [1].

[1] For more on the Befunge programming language, see http://en.wikipedia.org/wiki/Befunge.

Parts of this book are scrupulously sourced – for example, Cox makes some very nice distinctions between Lacan and Hannah Arendt – but the creator of the programming language that is the subject of the opening argument doesn’t deserve citation, presumably because the kind of mechanic or drudge who would actually write a compiler is obviously insufficiently human to deserve one. Elsewhere, Cox urges resistance to Javascript because "it is proprietary, indeed owned by Google." This point might be interesting, were it true. His footnote leads to a wiki page at LibrePlanet which links, in turn, to an essay by Richard Stallman; apparently, Cox misunderstood Stallman’s opposition to Gmail (a Google Web service) to mean that Google owns the underlying language. Stallman’s polemics against software property are briefly mentioned elsewhere in the book, but his actual art — the beautiful and immensely influential EMACS editor — is not.

It’s not just Stallman. You won’t find Kernighan here, or Ritchie. Bill Atkinsons’s not around, nor Bricklin, and there’s no joy for Bill Joy, nor does Lisa Friendly’s JavaDoc find a friend. You won’t find Sutherland’s Sketchpad, or Smalltalk, or The Demo. Knuth appears only for a cameo on literate programming. Ward Cunningham’s wiki was beautiful code (though modern incarnations are covered with ugly encrustations). Charles H. Moore’s FORTH was gorgeous. So was John McCarthy’s LISP. And there’s no hint of the work programmers do with Iverson’s APL and Wall’s Perl to express complex ideas in a tiny, tiny compass, a game as intricate as a villanelle and as delicate as haiku.

In fact, Reading Code seldom looks at any code that does something, code that might dirty its hands with actual work. Instead, we have things that look like programs and make pithy declarations about capital and labor. Every beginning student, learning that a variable name is simply a label and that the machine does not know or care what the label means, spends a day or two playing silly games.

for (teacher = every + fracking + grownup) { frack = you; }

 

There’s a lot of that here. And there’s some mild cleverness, like referring to a program that recursively deletes your Facebook friends as a form of (social) suicide. But none of it is really code, and a lot of it isn't quite as clever as it thinks.

The problem we face in thinking about code aesthetics is twofold. First, code is big, and the printed page is small. When we write about novels or epic poetry or a Collected Work, we assume that the reader is generally familiar with the work, that we are exchanging insights about familiar things. It’s not clear that MIT Press expected the audience for this volume to be able to read code, but there is no hint in the book that the authors expect readers to have any shared experience of it.

Second, code works. It does stuff. Its hands are dirty. This seems to unnerve the code aesthetes as much as machine aesthetics unnerved so many people in the 19th century. How could stone and steel be anything but ugly? Viollet-le-Duc had an answer, and Ruskin had another, and then Louis Sullivan told us that the tall office building "must be every inch a proud and soaring thing, rising in sheer exultation that from bottom to top it is a unit without a single dissenting line." Architectural beauty does not depend on ornament any more than delicious food depends on folding napkins into pheasants; to understand, we must simply have sympathy for things, their inherent tendencies and their purposes, their fabric and their fate.

What Cox and McLean overlook, alas, is that software aesthetics are in the midst of a profound revolution. For years, aesthetic discussion was polarized between two camps: those who advocated provability or at least mathematical rigor, and those who prized clarity. The mathematicians (also called “neats”) prized concise languages and intriguing formalism: LISP and Scheme, APL and Prolog. Their opponents (“scruffies”) prized structural clarity and expressiveness: Algol and ADA, C/C++ and Unix Tools, Java and Javadoc, Smalltalk. Neats wrote lovely little things; scruffies wrote exciting big things. That’s changed in the last five years in the wake of Design Patterns and Refactoring, Agile, and the tiny methods style. Today, scruffies still write large, but those programs are made up of lots of tiny bits, bits that look like the work of the neats. And the neats, too, can suddenly find a place for their work in the middle of a Web of small, loosely joined pieces. Spuybroek sees this in The Sympathy of Things, but there’s really not the slightest hint of it here.

Cox and McLean fancy themselves members of a radical left that abjures corporate control and detests "neoliberalism". In practice, they've gone all the way back to Versailles, dressing up as working folk and holding working-folk tools and cherishing clever little jokes that display their leisure-class status and superiority to work.