WEEK 2: CRITICAL + CREATIVE CODING
by Teddy Roland
Week 2 Threads:
Week 2: Creative and Critical Coding (Main thread)
Week 2: Creative and Critical Coding. Coding as Method?
Week 2: Critical and Creative Coding – Calvinball and Coders
Week 2: Poetry as Code? Code as Poetry
Week 2: Rando by Ben Grosser (Code Critique)
Code Critique: A Turing Machine in a Spreadsheet
Code Critique: JS Accessibility Hack
Code Critique: Processing Samples from The Nature of Code
Code Critique: analysing code from a website
Code Critique: Heinz von Foerster and Ordering Machines
Also Discussed:
Week 1: Gender and Programming Culture (Main thread)
Code and computer’s creativity? Hmmm…
Week 2—
The second week of the Critical Code Studies Working Group 2018, themed Critical and Creative Coding, was led by Margaret Rhee, John P. Bell, and Evan Buswell. Although all three use code in their work, they do so in very different ways, and the discussions this week explored the affordances and risks of coding in conjunction with interpretive and creative work. The main thread opened up several of the issues that would be revisited in various lights over the week. These include the kinds of knowledge that operate in code versus prose writing, the poetics of code, the specter of neoliberalism that haunts critical making, and the role of experimentation in opening new political and intellectual possibilities.
Among the provocations that Rhee, Bell, and Buswell offered in their opening remarks, one was particularly generative: What is the relationship between Critical Code Studies and writing code?
Opening with a moment of self-reflexivity, Jeremy Douglass pushes us to think about the meanings of “critical” and “studies” when we refer to the body of CCS work. Each of these terms is multiple, and in fact, Douglass suggests that this multiplicity is essential to the field: “creative code is the object (or byproduct) of multiple kinds of attention [from our critical reading practices].” The meanings of these terms are further refracted by the question of whether we are talking about writing our own code or reading someone else’s.
Taking up the latter, Jim Malazita encourages us to conceive an ecosystem of coding and critique. This conception is modeled on Howard Becker’s “Art Worlds” analysis, where “artists, art historians, and art critics all practice different kinds of knowledge-making, [yet] they are also all a part of a mutually constitutive creative apparatus.” Buswell develops this conception by observing that there is an entrenched division between computer science skill sets in the academy and industry. That is, academic CS tends to privilege theory, while industry relies on programmer’s coding chops. In this light, CCS offers a bridge, since it incorporates both.
If this conjunction of humanistic study with the CS department feels too close for comfort, Mel Stanfill urges us to set these issues against the backdrop of the crisis of the humanities and their devaluation in the academy. Taking up this stance, Jamal Russell argues that the neoliberalization of the academy is precisely the motivation for CCS. In his account, coding is an inherently interpretive—and, indeed, humanistic—enterprise, but a variety of economic and cultural factors mask this fact. The duty of CCS is to unmask the already poetic aspects of code, simultaneously confronting power on its face and re-centering humanistic inquiry.
Addressing that dichotomy from the other side, Samuel Pizelo pushes back on the oft-assumed difference between production and interpretation. That is, code-writing is often framed as a form of production, while reading (and essay-writing) are framed as interpretive and therefore non-productive. However, Pizelo argues that this is not the case. Buswell develops the point by noting that essay-writing about code is a special type of production, since it mediates an existing product.
Coding as Method
Evan Buswell opens the discussion about coding as an humanistic method with a challenge that is all too familiar to CCS and DH: the accusation of neoliberalism. Citing an infamous article published in LARB, Buswell takes seriously that charge that academic funding schemes might be cynically displacing traditional humanistic work with uncritical skills, such as coding. In this sense, the code that many of us write is simply the “meaningless precipitate” of a neoliberal regime. Yet as Buswell points out, “if the materialist study of ideology has taught me anything, it is that meaningless precipitates don’t stay meaningless for very long.” The question is, what does that precipitate do? How does it become meaningful?
In order to begin answering these, Buswell offers an object of study from his own research: a series of programming languages he is writing that take an alternate path from the historical mainline of computer science. To wit, his Noneleatic Languages handle a program’s code and state simultaneously, rather than keeping them separate. Daniel Temkin and Kai Zhang articulate versions of a question about what kind of thought these programming languages fosters, and its pre-Socratic philosophic precedents. Borrowing language from Giuseppe Torre, such a language constitutes a “speculative counterhistory.”
Taking up the characteristic feature of Buswell’s programming language, Martin Erwig finds it also in a surprising location: the spreadsheet. Each cell simultaneously contains a value and the formula for producing that value from those of other cells. Mark Marino opened another thread (Code Critique: A Turing Machine in a Spreadsheet) which takes up this feature of spreadsheets explicitly, and the conversation spilled over into Week 1: Gender and Programming Culture (Main Thread). There the question is raised about “whom else might we include” in the history of programming, if we take spreadsheet-as-programming seriously.
Dennis Tenen and Andrew Pilsch take up the thread’s initial questions more directly. For Tenen, the problem of interpreting code is cast in terms of labor. Too often this is hidden, so his research group uses version control, such as in GitHub, “to make the labor visible and therefore available to valuation.” Pilsch describes how the act of coding can be instrumentalized in the process of argumentation. Taking the media philosopher Vilém Flusser’s writing practice as a model, translating a text between languages is a way for the author to feel out the different facets of an argument and to see it more fully.
Calvinball and Coders
John P. Bell encourages us to look for sites creativity within quotidian coding practice. If it is uncontroversial in CCS that coding is itself pleasant or playful, then he asks us “What code have you seen that suggests a programmer is playing even when the goal of the program is functional?” In order to dramatize this point, Bell identifies a fundamental similarity between one of the principles of good coding, “Don’t Repeat Yourself” (DRY) and the rule-structure of the fictional game Calvinball, as played in the comic strip Calvin & Hobbes. In Calvinball, players make up the rules as they go, where the only rule is never to “play it the same way twice.” Similarly, a convention of good code is never to write two functions that perform the same operation. Bell suspects that programmers simply “enjoy creating new mechanisms,” rather than duplicating existing work.
DRY as a principle can be framed as local (within-program) or global (across programs), and a major line of discussion takes up the latter. The global frame directs our attention to code re-use. As Jeremy Douglass points out “Race, gender, and power is one interesting way to think about this question of tracing origins, and one of the many ways reuse and creativity are related.” Writing a new program means that the coder gets to solve the new, playful problem, but it is essential to keep in view that the coder “stands on the shoulders of millions of lines of APIs, libraries, frameworks, operating system code and network code, et cetera.”
In response, Michael Widner offers an alternate model of authorship from the medieval period where not only do authors cite previous authorities but if we “Add in the networks of labor that produced medieval manuscripts—scribes, illustrators, binders, etc.—and you have a model that I think more closely approximates how contemporary developers work.” Mel Stanfill picks up from this model to ask about the forensic examination of networks of reuse. Douglass points to version control software as a source of abundant material for forensic methods, yet he cautions that these too have blind spots.
Evan Schauer and Samara Hayley Steele both turn to other fields where they identify DRY as an animating principle. In particular, Steele identifies communities of rule-based game players, where the application of DRY (or not) is a matter of national culture.
Poetry as Code? Code as Poetry
Margaret Rhee opens the conversation with a series of gestures toward intersections of code and poetry. These points are drawn from both criticism and creative work in her own practice: “So primarily I will discuss code through my work as a poet. It has been an ongoing investigation of this idea of invented languages.” Two productive gestures that Rhee introduced were that toward Helen Vendler’s poetry criticism, which Rhee articulates as a search for “the ‘codes’ in poetics,” as well as a set of writing prompts for creative writers, partly based on a collaboration with Mark Marino.
A major line of discussion asks where exactly Vendler’s “codes” are to be found. Samuel Pizelo warns against fetishizing the poetic text or programmed code as such: “Too much attention on the object obscures all of the social labor being done to sustain the possibility that this object ‘means,’ and continues to mean through time.” Gerol Petruzella initially locates the meaning-making process for a given piece of code in the run-time of the operating system. However, in conversation with Bell — and upon consideration of the code-poetry piece “AI Prison,” from another thread (Code and computer’s creativity? Hmmm…)—their attention turns to physical hardware. Jamal Russell emphasizes the interface as the point of contact between code and coder, which introduces not only writing conventions but ideology. At that point, “social labor” is reintroduced as a creative and interpretive concern.
Creative works that play on the relationships between code and poetry were also discussed and produced. Kristopher Purzycki shared work that he has created while copyediting cream city review. Using regular expressions for find-and-replace, Purzycki co-authors, along with the machine, new texts that emphasize the latter’s perception of human language, especially of human-language characters as exchangeable. Adam Haile explores alternate systems of language constraints by translating William Carlos Williams’s “This Is Just To Say” into the syntax of a symbolic-expression language (in the Lisp family). The lines unfold differently than in the original poem, and it ultimately produces a function addressed to “you.”
On the other side of the code-poetry divide, Daniel Temkin discusses esoteric programming languages. Like Marino’s code poem that prints a repeated word, several languages deliberately obscure their syntax by using a single word, such as “Ook” or “Chicken.” As Temkin puts it, these “[bring] our attention to the surface layer of code,” instead of the functional program. For Marino, this is a productive defamiliarization: “By challenging what programming looks like, how code operates, [esoteric programming languages] challenge how and what code means.” Indeed, the free play of well-formedness and nonsense might be one good definition of poetry. Articulated this way, it builds a bridge to precisely the problems that interest CCS.