Strands forming a glyph as part of a short program computing the Fibonacci sequence in the esolang Rivulet.


From the MIT Press:

A riveting collection of one artist’s many approaches to esolangs—esoteric programming languages—showcasing the form’s limitless artistic potential. In Forty-Four Esolangs, Daniel Temkin challenges conventional definitions of language, code, and computer, showing the potential of esolangs—or esoteric programming languages—as pure idea art. The languages in this volume ask programmers to write code in the form of prayer to the Greek gods, or as a pattern of empty folders, or to type code in tandem with another programmer, each with one hand on the keyboard, their rhythm and synchrony signifying computer action. Temkin includes languages written over the past fifteen years, along with some designed especially for this book. Other pieces are left as prompts for the reader to simply consider or perhaps to implement on their own. Esolangs are a collaborative form. Each language is a complete world of thought, where esoprogrammers build on the work of esolangers to make new discoveries. The language Velato, for instance, asks programmers to write music as code; while the language creates constraints for the programmer, each programmer brings their own coding and musical sensibility to the language. Other pieces are pure poetic suggestion in the legacy of Yoko Ono’s event scores. These ask the programmer to, for example, follow the paths of the clouds over a single day and construct a language in response that uses those movements as code. Just as Ben Vautier claimed everything is art, this book blurs the lines between computation and everything else.

Homonymic symbols encoding a multivalent statement with multiple GOTO interpretations in the esolang Valence.


Forty-Four Esolangs is a part of the Hardcopy series at the MIT Press edited by Nick Montfort and Mary Flanagan. From their series forward:

Hardcopy features computational artworks that manifest themselves in print. Works in the series engage with and arise from computation in culturally important ways. The series is a space for (among other things) books that are computer-generated by artists and poets, whether they include text, image or both; print works based around glitched media formats; ones that feature type-in programs with sample output; and ones arising from online interaction with automated agents.

For this Critical Code Studies Working Group book discussion of Forty-Four Esolangs we may begin with a framing and a common starting point of a few selected passages (provided below). To situate the provided selections it is important to understand the structure of Temkin's book, which draws on Sol LeWitt's distinction between "concept" and "idea" in conceptual art and adapts it to code art practice. Accordingly Forty-Four Esolangs enumerates the presentation of 44 conceptual "Prompts" in the first half of the book (Language 0, Language 1, Language 2...). The book then presents variously-implemented "Realizations" in the book's second half, each named ("Velato (2009)", "Olympus (2022)", "FatFinger (2017)"...) and each corresponding to a numbered Prompt.

This week in our Working Group is organized around the topic "Where is the Critical in Critical Code Studies?" -- and it makes particular sense at this moment for us to unpack the critical heft behind Temkin's works of "pure idea art" in a conceptual art tradition. Forty-Four Esolangs features an excellent forward by Allison Parrish, who frames Temkin's code art practice as aesthetic-political as she draws a line departing from Peter Naur's notion of the programmer's abstract “Theory Building View” through to Lillian-Yvonne Bertram's "Of course, programming is political. How could it not be? No one is doing anything in coding without someone else.” Parish arrives here by way of a key passage from the conclusion of Amy J. Ko's "What is a Programming Language, Really?" (2016):

"[W]e understand what [programming languages (PL)] are formally and we increasingly understand what they are as tools. Other agendas, particularly those that probe the human, social, societal, and ethical dimensions of PL, are hardly explored at all. As researchers, we should be concerned with every view, and see each as an opportunity to understand holistically how PL can shape our world"

Selections from Forty-Four Esolangs are provided here as shared starting points for discussion. The short excerpts include the author's Preface, the manifesto-like "Sentences on Code Art", three conceptual Prompts (4, 40, and 41), and three corresponding Realizations ("Cloud Computing", "Rivulet", "Valence"). The selections are embedded and attached below along with linked resources, including the source code for two realizations, corresponding online interactive editor for each, and some introductory tutorials / documentation. Consider trying out the examples given in the reading selections (or exploring your own creations).

Temkin's work may illuminate (and be illuminated by) LeWitt's conceptual art, Montfort and Flanagan's print computational artworks, Naur's "Theory Building View," Bertam's "programming is political," or Ko's "human, social, societal, and ethical dimensions." However, in the end, we may return to the bare question: What are Temkin's esolangs? What is the art of esoteric code? Thank you for joining this discussion.

-- Jeremy Douglass, CCSWG 2026


For Discussion:

• What is the relationship of esoteric code to code in culture?
• How does esoteric code relate to conceptual art?
• What do these programming languages look like through the lens of software engineering and computer science?
• What do they look like from the point of view of the history of computation?
• How is Forty-Four Esolangs related to the concept of "print computational artwork"?
• How do we see Bertram's "programming is political" or Ko's "human, social, societal, and ethical dimensions" in this work?

Resources:

• Realization 40 (Rivulet) [source code] [online editor] [introduction]
• Realization 41 (Valence) [source code] [online editor] [introduction]
• Chinchilla, Chris. "Esoteric Languages Challenge Coders to Think Way Outside the Box: Daniel Temkin’s new book dives into the coding exercise/art form." IEEE Spectrum, 04 Sep 2025. [Feature author interview]

Forty-Four Esolangs--excerpts (Preface, Sentences on Code Art, Prompts 4,40,41, Realizations 4, 40, 41):

For Discussion:
Where is the critical in critical code studies?
What do you feel is the most productive marriage of critical and technical inquiry?
What code readings (articles or writings or other) marry these ideals effectively?
What are examples of discussions of code objects where one side or the other of this spectrum has dominated or is more needed?
What are your concerns in this debate?

Read the (unedited) transcript of our video introduction here.

This week we're running a collaborative exercise to try vibe coding for yourself and reflect on the experience. Rather than an abstract prompt, we're working with a specific historical object which is Christopher Strachey's Love Letter Generator from 1952.

Christopher Strachey (1916-1975) stands as one of the key figures whose work we now recognise as a foundational transitions in computational culture. The Stracheys belonged to the Bloomsbury Group, the group of intellectuals including Virginia Woolf, John Maynard Keynes and Strachey's uncle Lytton Strachey, which makes his later computational work all the more interesting for crossing of cultural and technical domains.

He was a pioneer in programming language design and denotational semantics, Strachey programmed the first computer music in England in 1951, rendering the National Anthem on Manchester's Ferranti Mark 1, followed by recordings of "Baa, Baa, Black Sheep" and "In the Mood" captured by the BBC. More significant still, in 1952 he created a love letter generator for the same machine that represents the first known instance of computer-generated literature, a development that prefigures contemporary anxieties about LLMs whilst also gesturing towards the literary experimentalism of his milieu.

His later development of time-sharing concepts in 1959 points to the infrastructural transformations that enable the distributed computational environments we now inhabit. What makes Strachey's life so fascinating is how it demonstrates the convergence of cultural, technical and literary spheres, collapsing distinctions that are difficult to cross over, even today.

The (literary) significance of the Love Letter Generator extends beyond its curiosity as an early version of computational culture. It seems to be a parody of one of literature's most codified genres, the love letter. It contains conventional declarations, expected rhythms of longing and affirmation, etc.. Strachey's algorithm (which sadly we seem to have lost) might be what the Russian Formalists would call a device of amatory writing, revealing the "templates" that structure even our most intimate texts. The generator's outputs read either as both sincere and satirical, occupy the same uncomfortable space as Oulipian constraint-based writing or Burroughs's cut-ups, which would emerge a decade later. The fact that Strachey drew his vocabulary from Roget's Thesaurus, shows fascinating connections to the idea of a systematisation of language. Perhaps this deepens the irony as the love letter, supposedly a singularity of expression, is revealed as a combinatorial operation on an inherited lexical dictionary. This might make us think of the generator not just as an engineering experiment but as a work of literary theory made executable, a machine for demonstrating that romantic discourse, like all discourse, is structured by rules that precede and exceed the speaking subject.

Your task: use an LLM to create your own version of the Love Letter Generator, then document what happens.

You can use our new CCS workbench or any other LLM to help co-create it

Why Strachey?

The Love Letter Generator is arguably the perfect historical antecedent for vibe coding. Written for the Manchester Mark 1, Strachey's algorithm generates "love letters" by filling sentence templates with words randomly selected from lists compiled from Roget's Thesaurus. The original code is lost, but the algorithm has been reimplemented many times.

A sample output:

DARLING SWEETHEART

YOU ARE MY AVID FELLOW FEELING. MY AFFECTION CURIOUSLY CLINGS TO YOUR PASSIONATE WISH. MY LIKING YEARNS FOR YOUR HEART. YOU ARE MY WISTFUL SYMPATHY: MY TENDER LIKING.

YOURS BEAUTIFULLY

M. U. C.

This raises the follwing questions:

1. The letters are grammatically correct, emotionally legible, yet produced without actual understanding. Strachey noted his interest in how "a rather simple trick" could produce "an illusion that the computer is thinking", anticipating both the ELIZA effect and what I'm calling elsewhere the "competence effect," but for text generation rather than dialogue.

2. Who wrote these letters? Strachey? The machine? Roget (whose Thesaurus supplied the vocabulary)? This question of distributed authorship maps directly onto vibe coding's triadic hermeneutic structure.

3. Both Strachey and Turing were gay men working during the 1952 prosecutions. Jacob Gaboury reads the generator as "pure camp", as an exultant love of the artificial. The gender-neutral, anonymous letters can be read as a quiet act of resistance.

4. There was a Code Critique thread on the Strachey Love Letter Algorithm at the 2024 CCSWG, proposed by Titaÿna Kauffmann. Key questions included: How is reimplementation a reinterpretation? What does it tell us about the legacy and "reborn-digital" heritage of Strachey? How can we "queer" this narrative through CCS? This questions remain (even more) relevant to vibe coding.

The Sprint Structure

Days 1-2: Vibe code your generator

Choose an LLM (Claude, ChatGPT, Gemini, Copilot, the CCS workbench or whatever you have access to) and prompt it to create a Love Letter Generator. You might, for example,

• Ask it to recreate Strachey's original algorithm
• Ask for a "love letter generator" without mentioning Strachey
• Share Montfort's reimplementation and ask for modifications
• Try different approaches and see what emerges
• Remember to keep your prompt history. This becomes a primary text for critical reading.

Days 2-4: Document the cognitive modes

As you work, you might want to pay attention to, for example,

• Cognitive delegation: Where did you offload judgment to the LLM? Did it lead you down unproductive paths?
• Productive augmentation: Where did human architectural control combine effectively with machine implementation?
• Cognitive overhead: Did managing the LLM's context or correcting its assumptions take you significant effort?

Note any moments where the "competence effect" appeared, which is where the LLM's output looked ok but was subtly wrong, or where its apparent understanding masked a deeper misunderstanding.

Days 2-7: Share and compare

Post your reflections to this thread (and the code if it is short enough - consider using the "Spoilers" tag to make the post manageable by others.

1. Does your LLM's version resemble Strachey's structure, or does it "improve" it?
2. What did the LLM add or subtract?
3. Is the output a reimplementation of Strachey, of Montfort's reimplementation, or of the concept of a love letter generator?
4. How do we read the differences critically?
5. What does your prompt history reveal about the distribution of agency?

Resources

Strachey's Algorithm

• Nick Montfort's Python reimplementation: https://nickm.com/memslam/love_letters.py
• Interactive version: https://www.gingerbeardman.com/loveletter/
• Wikipedia: https://en.wikipedia.org/wiki/Strachey_love_letter_algorithm
• David Link's Manchester Mark 1 emulator reconstruction: https://alpha60.de/art/love_letters/
• Previous CCSWG thread: https://wg.criticalcodestudies.com/index.php?p=/discussion/152/code-critique-strachey-love-letter-algorithm-thread
• The Critical Code Studies workbench, which allows you to create code within the tool, https://wg.criticalcodestudies.com/index.php?p=/discussion/205/critical-code-studies-workbench

The Core Love Letter Logic

The algorithm is remarkably simple. From Montfort's reimplementation:

def longer():
    return (
        ' My'
        + maybe(adjectives)
        + ' '
        + choice(nouns)
        + maybe(adverbs)
        + ' '
        + choice(verbs)
        + ' your'
        + maybe(adjectives)
        + ' '
        + choice(nouns)
        + '.'
    )
def shorter():
    return ' ' + choice(adjectives) + ' ' + choice(nouns) + '.'

It contains a template plus word lists. It can be understood quickly and reimplemented in any language, and which makes it ideal for observing what LLMs do when asked to recreate it.

Critical Reading

• JSTOR Daily: "The Love Letter Generator That Foretold ChatGPT": https://daily.jstor.org/the-love-letter-generator-that-foretold-chatgpt/
• Paul Curzon's description from the Wayback Machine.
• Gaboury, J. (2013) ‘On Uncomputable Numbers: The Origins of a Queer Computing’, Media-N: Journal of the New Media Caucus [Preprint]. Available at: https://median.newmediacaucus.org/caa-conference-edition-2013/on-uncomputable-numbers-the-origins-of-a-queer-computing/

Vibe Coding Discussion

This exercise lets us examine several questions

• When an LLM "reimplements" Strachey's code, what is it actually doing? Is it reading Montfort's version? Training data that includes discussions of the algorithm? The concept filtered through countless blog posts?
• Does your LLM produce something that looks like Strachey's generator but operates differently? How would you know?
• From Strachey (1952) to ELIZA (1966) to vibe coding (2025) can we trace how the "competence effect" intensifies as systems become more capable while remaining equally lacking in understanding. Does your experience of vibe coding confirm or question this genealogy?
• What would it mean to do critical code studies on the vibe coding session itself, including the prompts, the iterations, the failures, rather than on the resulting code?
• If Strachey's generator produces grammatically correct, emotionally legible love letters through pure combinatorics, what does this suggest about the relationship between literary form and authentic expression? Does the generator parody the love letter, or does it reveal something already present in the genre?
• Given the Bloomsbury Group's preoccupation with sincerity, intimacy, and the limits of language, particularly in figures like Virginia Woolf and Lytton Strachey, how might we read Christopher Strachey's generator as continuous with rather than discontinuous from that literary project?

I'll post my own attempt and reflections partway through the week. Looking forward to seeing what emerges and post your experiences below.

Picking up from the main book thread for Forty-Four Esolangs, we'll build a short program in Valence to show how syntactic ambiguity works in the language. It will be the Hai / Bye program, presented in full at the end of this post.

In English, we can form sentences like "Billy saw the group with the telescope," which resolve in two different ways: the group has the telescope, or Billy is looking through the telescope at the group.

Valence brings to programming this same structural ambiguity, where a line of code can hold multiple interpretations. When running the program, the interpreter forks the program at each ambiguous statement, allowing all versions of the program to play out in parallel. There is no single "correct" reading. This can be tried using the online interpreter / code editor.

Each Valence sign can be a command, an expression, a variable, or a literal value (by default, an octal digit). Its reading is determined by context: whether it is treated as a command vs. an expression, and how many parameters it is given.

Monads (signs that take one parameter), are written prefix. Using 𐅶 as example, it is written 𐅶x for parameter x. When a sign has two parameters, it is written infix,x𐅶y.

Each possible syntax tree for a line of code is evaluated; if we want to lock down these readings, we can explicitly mark a set of signs as a parameter by surrounding them with square brackets.

For example, take the line of code 𐅶𐅶𐅶:

Either the first sign is the command and it's a while loop, 𐅶[𐅶[𐅶]] (these are marked in red as there's a syntax error: the loop is never closed). Or the middle sign is the command, and it's an add/assign (+=), [𐅶]𐅶[𐅶]. The interpreter shows us a version of the code with brackets marking all parameters, with syntax highlighting displaying the command in green.

However, we don't have only two readings but four. There's a second form of ambiguity, because the third sign can be read as either a variable or a literal value (the octal digital zero). We use other signs to explicitly choose one or the other:

𐅶𐅶[𐅾𐅶] locks it down to mean the variable 𐅶, while 𐅶𐅶[𐆇𐅶] indicates the value 0. These are just one use of 𐅾 and 𐆇, which themselves have many different readings.

Here is a longer sample that relies on that second form of ambiguity, between literal vs. variable name:

[𐅶]𐆉𐆇𐆇
[𐆁]𐆉[𐅶]
𐅾[𐆇[[𐅾𐆁]𐅶[𐆇𐅻]]]
[𐆊]𐆉[𐆇𐅶]
𐆉[𐅻]
[𐆉]𐅶[𐆇𐅾]
𐆉[𐆊]
[𐆉]𐅶[𐆇𐅾]

When run in the editor, it has two interpretations, which execute in parallel:

video:

Below each of the two Interpretations are a State box, showing the final state of all Valence variables for that run. There are eight variables in Valence, and each corresponds to one of the signs used in the language. In the first interpretation, 𐆉 ends with the value 6, while in the right, it's given the value 8. Next to each line is psuedo-code showing how the interpreter reads it. For the left version, we have this:

𐅶 = 1
𐆁 = 𐅶
goto((𐆁 + 5))
𐆊 = 0
set_label(𐅻)
𐆉 += 2
set_label(𐆊)
𐆉 += 2

In lines 1 and 2, we assign the value 1 to 𐆁, followed by a goto expression. While Valence allows for structured sequencing with a while loop, it also has goto, which works in terms of labels. On line 5, we set the label 𐅻 (which literally sets the value of 𐅻 to 4 -- not 5, as line numbers are zero-based in Valence). The goto is not to either of those labels, but to the expression (𐆁 + 5). At that point in the program, 𐆁 has the value 1, so this resolves to 6. 6 is an alternate meaning of the symbol 𐆊, so we jump to the label 𐆊.

The right interpretation has a different reading for line 2: 𐆁 = 0. This is because, in the second line ([𐆁]𐆉[𐅶]), 𐅶 is read as both a variable and a literal (the octal value 0o0). As the literal value, we calculate a different label to jump to,𐅻, giving us the value 8 instead of 6. The syntax highlighting helps us read this, as variables are marked in orange and literals in yellow.

NOTE: If an evaluated expression is larger than eight, it mods eight (takes the remainder when divided by 8) to find the label to jump to. If two lines are labeled the same way, it jumps to the closest one

We can build on this to create longer programs that have multiple meanings. Here is the complete Hai/Bye program which extends our existing program, printing either "Hai" or "Bye" to the screen:

[𐅶]𐆉𐆇𐆇
[𐆉]𐆉[𐆇𐆇]
[𐆁]𐆉[𐅶]
𐅾[𐆇[[𐅾𐆁]𐅶[𐆇𐅻]]]
𐆉[𐅻]
[𐆉]𐅶[[𐆇𐅶]𐆇[𐆇𐅾]]
𐆉[𐆊]
[𐆋]𐆉[[𐅻]𐆉[[[𐅻[𐅻[𐆇𐆇]]]𐅶[𐆇𐅻]]𐅶[[𐅾𐆉]𐆁[𐆇𐆋]]]]
[𐅶]𐆉[𐅾𐆋]
[𐆋]𐅶[𐅻[𐆇𐅻]]
[𐆋]𐅶[[𐆇𐅶]𐆇[[[𐅻[𐆇𐆇]]𐅶[𐆇𐆁]]𐆁[𐅾𐆉]]]
[𐅶]𐅻[𐅾𐆋]
[𐆋]𐅶[[𐆇𐅶]𐆇[𐆇𐆊]]
[𐆋]𐅶[[[𐅻[𐆇𐆇]]𐅶[𐆇𐆊]]𐆁[𐅾𐆉]]
[𐅶]𐅻[𐅾𐆋]
𐆋[𐅾𐅶]

Below is the interpretation of that program. The "Hai" and "Bye" differ only in how line 3 is interpreted:

𐅶 = 1
𐆉 = 1
𐆁 = 𐅶 (for Bye) | 𐆁 = 0 (for Hai)
goto((𐆁 + 0o5))
set_label(𐅻)
𐆉 += (0 - 0o2)
set_label(𐆊)
𐆋 = cast(char, (0o105 + (𐆉 * 0o3)))
𐅶 = 𐆋
𐆋 += 0o50
𐆋 += (0 - (0o17 * 𐆉))
𐅶 APPEND 𐆋
𐆋 += (0 - 0o6)
𐆋 += (0o16 * 𐆉)
𐅶 APPEND 𐆋
print(𐅶)

On line 2, we set 𐆉 to 1. In the Bye version of the program, we don't skip line 7, which subtracts 0o2 (octal 2), giving us -0o1. This single change affects all the following calculations.

On line 9, we assign to 𐆋 0o105 + (0o3 * 𐆉), producing 'H' or 'B' depending on the value of 𐆉. This is then copied to 𐅶, which will become our final output string. On lines 11 and 12, we assign𐆋 += (0o50 + (-0o17 * 𐆉)), getting us from 'H' to 'a' or from 'B' to 'y'. For the third character, 𐆋 += -0o6 + (0o16 * 𐆉). Each character is appended to 𐅶, which is printed on the final line of the program.