Aesthetics

1 REM up comma up and away exclamation point enter

5 print C H R dollar sign open parentheses 147 close parentheses colon REM clear screen enter

10 V equals 53248 colon REM start of display chip enter

11 poke V plus 21 comma 4 colon REM enable sprite 2 enter

12 poke 2042 comma thirteen colon REM sprite 2 data from 13th B L K enter

20 for N equals zero to 62 colon read Q colon poke 832 plus N comma Q colon NEXT enter

30 for X equals zero to 200 enter

40 poke V plus four comma X colon REM update X coordinates enter

50 poke V plus five comma two hundred minus X colon REM update Y coordinates enter

60 NEXT X enter

70 GOTO thirty enter

200 DATA 0 comma 127 comma 0 comma 1 comma 225 comma 192 comma 3 comma 255 comma 224 comma 3 comma 231 comma 224 enter

210 DATA 7 comma 217 comma 240 comma 7 comma 223 comma 240 comma 7 comma 217 comma 240 comma 3 comma 231 comma 224 enter

220 DATA 3 comma 255 comma 224 comma 3 comma 255 comma 224 comma 2 comma 225 comma 160 comma 1 comma 127 comma 64 enter

230 DATA 1 comma 62 comma 64 comma 0 comma 156 comma 128 comma 0 comma 156 comma 128 comma 0 comma 73 comma 0 comma 0 comma 73 comma 0 enter

240 DATA 0 comma 62 comma 0 comma 0 comma 62 comma 0 comma 0 comma 62 comma 0 comma 0 comma 28 comma 0 enter

RUN enter

This was one of the first if not the first piece of graphic code I typed onto my first computer, trying to understand programming. I think the year was 1985 or 1986. I copied the exercise from a C64 manual,[1] and the other day, this is exactly what I did again – with the help of an occasionally crashing C64 emulator and my friendly home computer support system, otherwise known as my partner.

The simple programme is 16 lines of code in a language called BASIC, Beginner's All-purpose Symbolic Instruction Code, originally released in 1964 and heavily based on Fortran. The five-line data set at the end comprises of three-figure subsets corresponding to the three 8-dot series that make up one row of the 21 columns (plus one) of the sprite; the code before that positions the sprite in a manner that makes it appear to move. This particular sprite looks like a turquoise hot air balloon with a Commodore logo moving in a diagonal across the screen – hence, the up, up, and away part on line one. Except the version in the manual does not do this, because line 50 has the original value for x instead of 200 minus x, so the balloon floats down, not up. In printed manuals – this was the time before Internet – trying to debug such errors, especially errors in data sets, was a pain in the butt (often very literally as you sat and tried to decipher whether the error was yours or in the instructions).

Beyond making myself sound old, why bring up programming in the context of artistic research in the performing arts, aesthetics and performance? The word ‘performance’, as Jon MacKenzie (2001) points out, includes the performance of machines, although from our perspective, today, the Ariane 5 might be more interesting a case than the Challenger.[2] More recently, Inke Arns (2005) has suggested code is a performative speech act and that the performativity of code as what draws artists to software. Although Arns does not develop these claims, artistic use of computer code can expose the cultural, social, aesthetic and political entanglement of what is usually represented as neutral – lines of code and what that code does.

So why the sprite? A simple analogy to artistic research would be that the performance practice is the balloon, and the audience is like the user who sees a balloon floating across the screen, whereas the artist writes the code, understanding not only how the balloon and its apparent movement is created but the process of translation to the machine. Moreover, just like a coder can deduct the balloon floating from seeing just the piece of code, an artist can see in another’s practice something that is indecipherable to audience. Trust me, it is much easier to speak code to someone who knows code, even if they work on LISP and you prefer HTML. So, in this simple analogy, art requires an understanding of practice not required of the audience, but artistic research remains a human practice. This is too simple an analogy.

On another level, you could claim the programme is an analogy of artistic research. The choice of a particular language results in a certain kind of translation between the coder and the computer that then performs the code. But the code is always written for the future: until the moment of execution – the RUN command – the code is in potentia, it does not yet perform. Reading code does not require executing code, although the likeliest execution of any code is a bug: an error message, a misshapen form, or the wrong direction for the floating balloon. Bugs force us back to the drawing board, so to speak, much like in research. Most of us, I would say, continue in order to fix previous bugs in our execution and document as REM lines to not forget why this part was here in the previous iteration.

However, computer coding is also an aesthetic pursuit for beautiful code. One thing the Commodore BASIC dialect does is wreck any sense of aesthetics in favour of getting as much juice out of the machine as possible – remember, this machine had exactly 64 kilobytes of Random Access Memory – that is: about 275 text-only tweets – seriously limiting its performing capability. So, for example, by cutting out all spaces within lines of code in maximum 160 character strings as multiple statements on a line execute faster, or using keyword abbreviation – question mark for PRINT, for example – would have allowed me to write the programme in less than half its length, especially if I eliminated the REM statements, the function of which is to describe, as succinctly as possible, what the code does at that point. REM stands for ‘remember’, they are, literally, documentation of the process. Such explanatory parts make it easier to change and debug the code later. In terms of artistic research, therefore, they are often the crucial parts, the examined parts, and often considered un-aesthetic.

In 1975, Edsger Dijkstra [1975] famously stated that "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." Giving lie to Dijkstra’s statement, the BASIC dialects home computers used in my youth are responsible for the game industry of today. Within three years of the release of the C64, games comprised 60 to 70 per cent of its software, and per capita, Finland had the highest number of C64s in Europe, roughly three for every hundred inhabitants.[3] Since they were able to optimise performance of code, many C64 programmers later did well in programming environments with serious limitations in performance capacity – such as in mobile phone coding.

Instead of the usual focus of aesthetics on the performed work as it appears to audiences (the sprite), artistic research focuses also on the aesthetics of the practice (the code). But the aesthetics of the end user are not the aesthetics of the coder and the machine does not care. My question is: should we?

What makes code elegant are qualities like legibility, clarity, form and style – aesthetic qualities that are, essentially, only visible on the level of the code, not in the end result. Because of concerns of not just performance but future change, the aesthetics of code tends towards a minimalism that, for example, abhors repetition of code and redundant explanatory notes. So, in my example, most of the REM statements apart from line 1. The REM statements, by the way, only perform for the human reader of the code, not for the end user or for the computer.

As with what makes mathematics beautiful, these philosophical issues about aesthetics of form and function in code are often raised, much argued, and very rarely defined. Again, the same is true of the research outputs of artistic research. The elegance in code does not always translate to performance or vice versa. The REM statements may seem redundant or overwhelming.

Despite the legacy of anti-aesthetic in modernism, it really is surprising how little we seem to discuss aesthetic qualities or aesthetics of experience in the practical parts of doctoral theses, conference performances, or research expositions. Yes, artistic research is not just the sprite, it is also the code that is performed and the process of creating that code. At its best, the aesthetic of the sprite and the code come together, the exposition of artistic research sharing the qualia of the art practice. But that still ignores who the code is for and what happens in the performance of it. It ignores the machine.

I could go on, make another analogy between the sprite and the ghost in the machine[4] but given the restraints of time that for me create a lack of potentia in this performance setting, I am skipping to a final provocation. Having taught in a doctoral programme of artistic research for a decade, I still do not identify myself with the discipline. Where is the bug in this code? Where and for whom does artistic research perform?

Sources:

Arns, Inke. 2005. “Code as performative speech act.” Arnodes, July issue http://www.uoc.edu/artnodes/eng/art/arns0505.pdf

Dijkstra, Edsger W. [1975] How do we tell truths that might hurt? http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html Accessed 1.11.2019.

McKenzie, Jon. 2001. Perform or Else: From Discipline to Performance. Routledge: London & New York.