I’ve used the experimental writing of Oulipo quite a lot here to talk about esolangs; Oulipean systems produce literary pieces through sets of constraints, esolangs are (often eccentric) rulesets for writing programs. While Oulipo uses a rigorous, scientific approach to shape the often less-rigorous activity of writing fiction and poetry, esolangs do the opposite: bring to the writing of code – something we at least attempt to do in a rigorous way – languages that are intentionally eccentric, opaque, or challenging.

Christina Lopes’s Exercises in Programming Style uses an Oulipean source, Raymond Queneau’s Exercises in Style, as its inspiration. While Lopes’s exercises are more practical, illustrating different approaches to problem-solving in code, the choice of Oulipo as a basis creates an interesting contrast between what style means in a literary text verse in the performative text of code. In the original, Queneau tells the same story 99 times: as a dream, as a mystery, in olfactory terms, or in permutations of words with 2, 3, 4, or 5 letters. Lopes writes a program with the same objective 33 times, each in a different style. Lopes differentiates style from a programming language, which itself encourages different approaches (she uses the everyman language Python in each example) and from design patterns; patterns may or may not be useful in a given program, but all code has style. 

The story Queneau chose to relate over and over in the original is hardly a story at all; it only has a narrative in the loosest sense, more of a series of loosely related events that happened to him one day, grouped around the mild coincidence of seeing the same stranger twice in the same day in a big city. This lack of structure allows Queneau to project profoundly different sensibilities onto it with each re-telling. It’s too mild and sprawling a story to take on a mythological quality, even after reading the many iterations, which allows each style to be read with new eyes. Some iterations highlight different pieces of information, downplay others, and project different emotional characteristics.

Each program in Lopes’s book is very different, but each achieves the same result, the evaluation of a text; in this case, counting the most common words appearing in text provided to the program. Lopes chooses about as un-Oulipean a text as she can, Austin’s Pride and Prejudice. Not only does each of her variations “read” differently to the programmer interpreting each version of the program, but they have differences in execution. The very first example, called Good Old Times is in an early ‘50s style, using no named variables or labels, but direct memory access. This is a familiar tack from esolangs (like brainfuck) that use direct memory access, along with language which trade off ease of use for more direct control by working closer to the machine. Interestingly, this example is far less efficient than many of the others in the book. 

The second example also works in a low-level style. Called “Go Forth,” it uses a Forth-like stack machine (again, written in Python) and no named variables, an approach we see across the board in esolangs, including mainstays like FALSE, Befunge and Piet. Here, the historical notes are fascinating: the stack machine was invented in 1945 by Turing but classified; it was invented independently about ten years later. Also, PostScript is stack-based! From there, Lopes turns to minimalistic styles: Monolith and Code Golf. Eventually she branches out into event-driven models, data-driven architectures and reflection / code generation. While some of are more familiar than others, the historical notes give critical context, and are often the most interesting parts of the book.

While Queneau’s styles each have a different emotional tenor, only the strangest of Lopes’s do, reflecting the differences in their projects and perhaps between writing and coding. There’s a style labelled Tantrum, which reacts to abnormalities by halting and shutting down in a silent tantrum. While this at first seems like an absurd way to code, she shows how it’s actually encouraged by some languages (Java in particular) and occasionally has valid uses. Lopes contrasts it with other styles (Constructivist, etc), not to compare one over the other objectively, but rather to show how these approaches clash when brought together, potentially leading to disastrous scenarios. In code, we are always building on others’ work (much like the collaborative nature of Oulipo works). To me, this is the most important argument Lopes makes for understanding code style: not only to become more attuned to the styles we’ve adopted, perhaps without realizing – but to understand approaches used in code we will inevitably come in contact with and how best to work in those modes of thinking.