Peter Wildman's thesis Deconstructing code that works (a paper and accompanying performance/installation) deconstructs not so much working code, but rather the rigid binary of runnability itself: whether a piece of text can be called "code." To explain why this is necessary, Wildman recounts the early days of code poetry and its debate over runnability, which has never quite gone away.

 

Code is a Text that Runs

In 2001, Alan Sondheim coined "codework," a term for the growing field of hybrid texts that read as both code and poems. This was an attempt to describe what was, like most emergent movements, a motley group of creators with very different intentions (Sondheim's paper, and some of the others referenced by Wildman, can be found on Monoskop's code poetry page). Before codework, it had as many different terms (rich.list, programmable poetry) as it did writers. While Sondheim's term caught on, the looseness of this new category of writing, along with some of his idiosyncratic vocabulary and ideas, was challenged, most notably by John Cayley. In a debate on the nettime mailing list (summarized here on Cayley's site), the two debated whether texts that are not code belong in the codework category at all. In what sense does poetry that can't be run as code belong to a genre that merges code and poetry? Yet the writing of perhaps the best known writer of the genre, Mez Breeze, is not easily confused with runnable code.

To esolangers, this debate might seem odd, as the opposite impulse is much more common: making code that is less traditionally code-like in appearance or logic -- or sometimes non-textual entirely: made up of emoji, music, or images. But it should not be a surprise that work by folks approaching this work from an experimental literary perspective are dominated by its textual qualities.

In 2002, Rita Raley's paper "Interferences: Net. Writing and the Practice of Codework" attempted to move past the executable/non-executable debate, describing it as the central issue in a first wave of critical discourse, now past. To her, the more interesting exploration is in the tension between natural languages and programming languages at work in writing like Breeze's. But here, Wildman argues that she is still trapped in the same dichotomy:

Raley attempted to reunify the field, or more precisely Sondheim and Cayley’s divided terms of reference, by incorporating the binary divide of executable/non-executable into the qualities of the field itself. She states that “codework tries on the whole to move beyond this schism - the code and its ‘work’ or operation - to make something new. It relies on this schism in order to produce its effects, but then there is a mixing, an interfusion, and something other emerges.” (Raley 2002, par 31) Yet, this reunification of codework has not taken hold as we can still see this schism being referenced fourteen years on.

Wildman's aim is not to re-litigate the boundaries of codework, but something more radical. Drawing from Derrida and Spivak, he wants to deconstruct the executable/non-executable binary itself, exposing the limits of this dichotemy, and allowing codework to embrace more esoteric computational approaches.

 

Contextual Evaluation

His first move is to consider esolanging practice, which points to the arbitrariness of what code looks like. He eases into the subject with joke languages that undermine the dignified tone of code while remaining equally functional. Here's what a cat program looks like in Chicken:

chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken
chicken chicken chicken chicken chicken chicken

Also considered are libraries that make the boundaries of an existing language more porous. Looking at JavaScript (the most chaotic popular language), he mentions both FuckIt.JS, a steamroller that deletes lines of JS that don't parse -- thus making the rest of the program functional -- and my own project FatFinger.JS, which allows misspelled JavaScript to run, by guessing at what the programmer had intended. 

Even without special tools to expand a language, its edges are often murky; and this is actually more apparent with the most conventional languages, as they have the largest number of competing implementations. As this ACM paper puts it, "Parsing is considered a solved problem. Unfortunately, this view is naïve, rooted in the widely believed myth that programming languages exist." In other words, how a language is defined is usually in terms of its executors -- which often have minor differences -- not their specs. Ben Olmstead (at first accidentally) exploited this in his legendary esolang, Malbolge, creating a schism in its language community between those who consider its model interpreter definitive and those who follow the spec.

From there, it is a smaller jump to conceptual languages, like those discussed in this esoteric.codes post, emphasizing the arbitrariness of not just the signifiers of code, but also the conceivable participation of the physical machines we usually mean when we say "computer." Marks in the sand can be code if they are interpreted by a system with enough complexity to reach Turing Complete status. It is practically a hobby now to find these accidental Turing Machines in all kinds of clearly unintended places.

Rather than simplifying the complexities of executability and code, a computer programming language that could execute a function within the computer by encoding all literal text reveals the complexities of how programming languages are designed and function... Works of Breeze, Memmott and Sondheim would be executable just as this paper would be executable. The existence of such a language compiler would make all readable literary works potentially executable, whether written online, in a book or in the sand.

Wildman points to not only a multitude of materialities, but also of histories, considering the cultural context of how programming languages were written and for whom. Why should code poets with native languages other than English use programming languages designed for English speakers? Ramsey Nasser's 'alb project (discussed here), an Arabic LISP language, addresses this. While designed to help Arabic speakers learn to code, the potential for code poetry was part of Nasser's vision. Also referenced is Angie Abdilla, CEO of Old Ways, New, a consultancy that embraces Indigenous approaches to technology to develop robotics and design that vary from normative assumptions of computing.

 

Exceptions as Exceptions to the Rule

While this tour of alternate computing sets up the key ideas in Wildman's thesis, the actual project does not use esolangs or invent new languages, but instead on the the varying contexts of a running program. He accomplishes this using exceptions (anomalous conditions that disrupt the normal flow of a program -- essentially errors). This choice allows him to work in a language more familiar to an audience of artists and academics likely to read such a thesis: Processing. It also means he can use any text he wants as code, since he doesn't want or expect Processing to validate it, but rather treat the text as a syntax error.

He begins by selecting a short quote from Cayley as the "code," with the sketch name JohnCayley:

The code has ceased to function as code.

Running this in the Processing environment (PDE), invokes an error:

expecting SEMI, found 'code'

with the helper:

Syntax error, maybe a missing semicolon?

In so doing, Wildman has asked the PDE to treat the sentence as Processing, regardless of its original context.

Throughout the codework discourse, through Sondheim, Raley, Cayley and Hayles, these texts are referred to as interface, surface, broken, natural language texts and set against programmable, narrow or pure codes. Despite being included/excluded within the field of codework, all of the theory posed by these academics above asserts that this binary position of executable/non-executable literal text exists and can be differentiated in these general terms. But any literal text placed within most programming language development environments will function or create a response within the computer

The thesis includes Processing's Java code that handles and reports the exception, emphasizing Processing's IDE as itself code. Had it failed to handle this syntax error, the IDE would have crashed. In a gesture that recalls Kittler, Wildman shows the futility of considering a running program in isolation, apart from the conditions of its execution. As many have experienced with Processing, a simple Processing sketch can produce inexplicable Java errors; these systems are permeable.

In the performance of his thesis, Wildman both performs his own thesis text as code, and crosses it out, recalling Heidegger's process of sous rature, as explained by Derrida and Spivak. In his opening, he quotes Spivak's intro to Derrida's Of Grammatology:

“If in the process of deciphering a text in the traditional way we come across a word that seems to harbor an unresolvable contradiction, and by virtue of being one word is made sometimes to work in one way and sometimes in another and thus is made to point away from the absence of a unified meaning, we shall catch at that word. If a metaphor seems to suppress its implications, we shall catch at that metaphor. We shall follow its adventures through the text and see the text coming undone as a structure of concealment, revealing its self-transgression, its undecidability… I am not speaking simply of locating a moment of ambiguity or irony ultimately incorporated into the text’s system of unified meaning but rather a moment that genuinely threatens to collapse that system.” (Derrida 2006, xcviii)

He begins by reading a short code poem, a random number generator, written in pencil. This is the first step in an elaborate ritual, performed repeatedly about 1500 times, taking 150 hours. The code poem is read aloud, and then run as Processing. The code poem has variable names referring to Breeze, Cayley, and Sondheim, the main characters in this drama; here they are not syntax errors, they are part of functioning code. As he erases the program, the eraser dust is brushed onto a large black mat, densest in the center and fading to black along the edges, recalling modernist painting and the red-on-black error messaging of Processing.

The output of the code poem is a number, indicating how many words Wildman will strike from his thesis, with a thick red line. He reads them aloud, and crosses them out. The thesis of course repeats the names of Breeze and the others used as a variables within the code poem many times. The words of his thesis and of the error they generate are printed together, the error varying depending on which lexical rule is first broken:

Badly formed character content (expecting quote, got e)

The sheet with the thesis text snippets and errors is then balled up and thrown into the corner, in a slowly growing pile of balled paper, resembling a Felix Gonzalez-Torres installation. When a page is completely crossed out, Wildman hangs it diagonally on the wall; its words still readable, but marked for elimination. The thesis is marked as read, executed; the output text and the code itself blurred together. Here is (silent) video documentation:

Deconstructing Code that Works Process from Peter Wildman on Vimeo. 

 

While the dichotomy of executability is at the heart of Deconstructing code, its power is in the invitation to rethink the other binaries of code that underlie much of codework. It is a call for code poets to consider the systems that code takes part in, to allow these to enter what is fundamentally a form of experimental poetry. It was wise of Wildman to bring the perspective of the esolang and greater hacker community into codework -- people who rebel against assumptions about how code is supposed to work, and take a playful approach at challenging them. Since bringing these communities together is the key mission of esoteric.codes, it's rewarding to see this conversation expanding. It is apparent in work like Will Hick's Esopo project, a code poet's answer to the Shakespeare esolang, taking a broad joke and finely tuning it for literary expression.

The reminder that most programming languages are geared toward English speakers is important; a poetic form that builds so directly on such a language should not passively reproduce those values. This is the question I'm most interested in seeing expanded in codework. The upcoming HASTAC conference in Vancouver, focused on decolinization and Indigenous approaches to Technology, will have a session on live coding. I'd love to hear from readers who have found more resources and discussions on this topic.

While the methodical performance using erasure and exceptions makes for a dramatic piece, it will be interesting to see Wildman's work continue, and if he will find other ways to deconstruct code poetic structures and the greater contexts of code. His code poetic works can be seen here, and here again is a link to the full thesis paper.