Pall Thayer’s Microcodes are short code art pieces written in Perl and presented on a website for viewers to read, download, and execute. Each code piece encapsulates tasks performed by artworks such as portraiture or memento mori. They follow on from Thayer’s earlier “Exist.pl”, which allegorized life, death and being using running Perl code.

This is a Romantic use of code, a projection of human experience onto mere material existence. Processes become lives or individuals, network sockets become voices or eyes. And in a Nietschean twist some of the code can be genuinely destructive for data. But it works the other way round as well, demonstrating that meaning can be found in or recovered from mere processes.

The program listings are presented on a modern, neutrally styled, website for download and execution. The code is licensed under the GNU GPL version 3 (or later), so everyone is free to use, study, modify and redistribute it. The use of the GPL should be a given for code art, but far too many artists are happy to take the freedom that they are given by other hackers and not pass it on. Thayer deserves credit for doing the right thing.

You can send modified versions back to be published on the Microcodes website, something that resembles social media and collaborative web projects, but this isn’t yet the focus of the project. Given the opposition between social media and computer programming that some commentators have tried to establish (myself included), it is refreshing to see a project that uses elements of both where both can add to it.

Historically, “microcode” is the inner programming of microprocessors such as the ARM or Pentium, the level below machine code. Thayer’s Microcodes are short (micro) programs (code) written in the programming language Perl. Perl is a well-established and popular language for scripting and for web programming. It is a more typographic language than many, with a rich and intentionally ambiguous syntax. This makes it ideal both for expressive programming and for visually interesting program listings.

Perl is installed on modern operating systems by default (and can easily be installed on Windows). Running a Perl script in 2009 therefore requires minimal geekery. But Perl is a strange-looking enough language, even compared to newer scripting languages and other C-style-syntax (curly-brace-based) languages, that using it emphasizes the strangeness of code and makes its structures visually noticeable.

Like any Perl script each Microcode creates a composition of relationships between operating system resources such as processes, network sockets and files. Unlike most Perl scripts this is the intended end result of the code, not a side effect of its execution or the means to the end of the program’s effects as for example a UNIX command-line tool. The process of executing the code is intended for contemplation rather than for instrumentalization. The incidental or contingent becomes the primary or key.

Information workers spend at least eight hours a day “in” the digital landscape of the computer or the network. This is their landscape. Software that depicts this environment is in a way the landscape or land art of the UNIX hegemony. It functions as paintings of Venice or as stone circles for hackers and for anyone whose life is touched by technology.

Software is both performed, as something that is written by a programmer, and performance, as something that performs a task. Making that performance the focus of the software’s execution makes the software the intended result and subject of both acts. Software debuggers observe and present the inner working of the operation of other pieces of software, but not of themselves. It’s a bad old joke in aesthetics that art is defined by its inutility. But it is true that code that does nothing other than what it does must in some way be doing (or being) itself and that if this is the intended result of executing the software then this must be intended to be interesting in some way.

When I was at art school I took up programming as one means of resisting the local hegemony of art-as-text under the stultifying academic regime of semiotics-and-Marxism. Programming is a specific, technical competence that cannot be replaced with “generic” textual or managerial skills. Artistic practice also consists at some level of technical competences. This upsets both managerialistic critics and curators (who need interchangeable and easily ventriloquised art) and managerialistic artists (who need interchangeable and easily ventriloquised artisans to actually make the products of their semiotic genius).

I, and others, have claimed that artists who use computers need to be able to program. Artists who, whatever their intent, accept computers as closed tools are often offended by this. But mastery of tools is a prerequisite for competent expression. There is the question of at what level this mastery needs to be demonstrated, though. If one wishes to be an Impressionist should one master colour theory while using pre-mixed oil paint in tubes or does one need to master molecular chemistry?

Thayer’s work is competent programming but as a project it is socially open. You don’t need to be able to program to appreciate or add to it. It can be taken and modified as an aesthetic as well as executable resource. Its framing as code is clear, but its presentation on a social site and its licensing under the GPL leave its use by other artists, whether programmers or not, open. It frustrates those of us who hoped to use code to draw a line in the sand by using code effectively as a social product and resource.

The creation of software that does nothing useful as a command-line tool is not comparable to too many artists’ technically incompetent use of medical equipment, mathematical equations or scientific theories as mere imagery in aesthetically competent artworks. Software has to run. Thayer’s Microcodes run, run correctly, and perform as specified.

A hacker and free software activist I know asked me what exactly makes the Microcodes code listings art (interestingly, they didn’t ask why they are code). I gave two reasons:

Firstly, the text of each program listing is short enough to be taken in as a single visual composition. When presented under the claim that they are art they therefore fall into the tradition of conceptual text-as-art. The tension between appearance and meaning that this implies is a live issue in art history and in art. There is an immediate and historical aestheticism or artistic-ness to the code.

Secondly, the behaviour of each program when it runs achieves no practical task as a command-line utility. It is therefore either useless or intended for some other purpose. The user must evaluate it using on their knowledge of what it does and how this relates to their experience of software. That is, on its aesthetics and iconography rather than on how it performs as a tool for some other external end.

This is exemplary code art. It makes strange the environment of the operating system and the command line. It creates an aesthetic representation, a meaningful resemblance in appearance but not function, of it in code as an object for contemplation. Microcodes has a balancing social component, but by being at its core unashamedly about code it allows that code to be about something of interest rather than the ostensive social or political content of the project just being an excuse to write code. This is code about the experience of being human in society in a time when being human in society is in no small part about the experience of code.

http://pallit.lhi.is/microcodes/

The text of this review is licenced under the Creative Commons BY-SA 3.0 Licence.