Authors: H. Scolnik, L. Talavera, I. Loiseau, M. Camuyrang, J. Perrez Iturrioz, E. Rocchi, C. Ruiz
Date: 1976
Language: Fortran

Source code

Context

Even in the early years of computer science, the idea that the world could be understood as a system that could be simulated by computers was already popular. Early digital simulations promised to understand and predict global trends acting as warning devices without offering ways to avoid their predicted futures. The LAWM (Latin America World Model), developed by a multidisciplinary team around Argentinian geologist Amílcar Herrera, deliberately tried to steer an early global community of world modelers toward solutions, not risks.With a focus on basic needs – like adequate housing, education or protein intake –, the model indicated a path towards optimal allocation of labor and capital to ensure the longest possible life expectancy. Their model showed that a global catastrophe was not imminent; with the use of optimization and planning, there were even ways for the less wealthy regions of the world to reach a standard of living as in the US or European countries.

The code is of double interest: it exemplifies both the grammar and lexicon of one of the earliest and most widely used high-level programming languages, Fortran, and the way computer programs are never neutral, but instead embody particular political visions.

Resources

• The Latin American World Model (a.k.a. the Bariloche model): three decades ago, a personal reflection by one of the authors.
• Catastrophe or New Society?: A Latin American World Model, the original publication around the LAWM
• SimPolitics: America’s Quest to Solve Politics with Computers, upcoming book by Fenwick McKelvey at MIT Press

Questions

• What role does Fortran (a Formula Translation language) play in translating concepts that are themselves beyond a formula (i.e. "basic needs")? As a response to the World3 model focusing on material realities, the LAWM proposes to focus on social and political factors: are one of these domains more amenable than the other to be translated into code "productively"?
• Is there some sort of isomorphism between the written code/running software relation and the model/simulation relation? Or is written code already a simulation of an existing conceptual model?
• How does the LAMW compare to World3 model, and what does that tell us of code's institutional ties in order to perform, not only mechanically, but also politically?

Credits

This source code excerpts has been contributed by Fenwick McKelvey and Markus E. Ramsauer.

Fenwick McKelvey is an Associate Professor in Information and Communication Technology Policy in the Department of Communication Studies at Concordia University. He leads “Machine Agencies” at the Milieux Institute. He studies digital politics and policy.

Markus E. Ramsauer is a PhD Candidate in the History of Science at the University of Vienna. Ramsauer investigates origins of global simulation models in relation to the Global South.

Rivulet is a language inspired by natural language; it has an internal logic, a coherence, but with no rational explanation. Rivulet relates to the Week 3 discussions, as it's part of the Source Code Exhbition, but it's also in Forty-Four Esolangs, discussed in Week 1.

It takes a while to understand the full syntax of Rivulet, but I want to focus here on only two aspects: first, the way that line numbers work in the language, and second in how "zero strands" are written.

Here is a single Rivulet glyph:

 1 ╵──╮───╮╶╮ 
 2  ╰─╯╰──╯ │  
 3     ──╮  │  
 5       ╰──╯ ╷

And here is pseudo-code for the glyph, which can be generated by running the interpreter with the -v for verbose option:

list2[0] += 0
list2[1] += 1
list1[0] += -16

The glyph begins and ends with glyph markers: ╵ and ╷. Each strand begins with a hook pointing up or left, which marks its beginning (strands without hooks or with hooks pointing in other directions are used for other types of strands not considered here). Each unit it moves to the right adds the value of that line number, and each movement to the left subtracts it. The line number it appears on marks a list element it is writing to; by default, it is an add-assignment (+=). First from the left is the strand beginning on line 2, which gives us list2[0] += 0. This is called a zero strand, and it has no effect on that list element, but is there so that the second strand beginning on line 2 can write to list element 1, for list2[1] += 1. Finally, it reads the third strand (reading from left to right), which assigns to list1. It moves to the left twice on line 5, subtracting 10, and then twice on line 3, giving us -16.

You may notice there is no line 4. In Rivulet, line numbers are successive primes. Line numbers don't need to appear in the code, but can be included as reference, as the Rivulet interpreter ignores all non-box-drawing characters. They also reset with each glyph. Why prime numbers? The compactness of the glyphs need numbers that grow faster than a linear progression, and less than exponential growth, so that one can represent large numbers without making the glyphs very large. Prime numbers hint at a deeper meaning, but this is primarily an aesthetic decision. I imagined what a programming language might look like had it developed like a natural language, with conventions that have an internal consistency, but no rational explanation.

The zero strand is needed often, to allow writing to list elements beyond zero. There are many ways to write them. Here is a set of zero cells writing to list1. Each of these is equivalent:

 1 ╵╰──╮╰───╮╶╮
 2    ─╯    │ │
 3         ─╯ ╰──╮
 5          ╭────╯
 7          ╰──  ╷

Running -v gives us this pseudo-code:

list1[0] += 0
list1[1] += 0
list1[2] += 0

But more specifically, the flow is:

list1[0] += (2*1) + (-1*2)
list1[1] += (3*1) + (-1*3)
list1[2] += (2*3) + (-5*5) + (-3*7)

Writing to list2, these are all zero strands:

 1 ╵╭─╮        ──╮
 2  │╶╯╶╮╰────╮╰─╯╶╮
 3  ╰──╮╰─╮ ╭─╯ ╭──╯   
 5    ─╯  │─╯   ╰────╮
 7    ╭───╯        ──╯
11    ╰────╮
13       ──╯         ╷

list2[0] += (-1*1) + (2*3) + (-1*5) 
list2[1] += (1*3) + (-3*7) + (4*11) + (-2*13)
list2[2] += (4*2) + (-1*3) + (-1*5)
list2[3] += (1*2) + (-2*1)
list2[4] += (-2*3) + (4*5) + (-2*7)

Any one of these can be used as a zero strand for list2. We would draw a strand -- one of these or another -- which gets out of the way of other strands we want to appear in the same glyph. Writing Rivulet is often a re-working of existing strands in order to add others to the glyph.

The Rivulet interpreter also includes an svg generator, which draws the strands as complete lines and colors them so that related strands are the same color (we have no strands that refer to each other here, since we are only dealing with the simplest kind of strand, that used for add-assignment):

And here is a complete Fibonacci program, using the same algorithm, the same "code," represented with strands that move differently through the space (and generated with different color themes):

More on Rivulet

• Rivulet interpreter (github)
• The original tutorial
• Intro to Rivulet by Jo Wood
• Syntax reference
• Hacker News discussion

For those who want to work with Software Heritage, the best practical guide available is a 2024 Programming Historian tutorial by Sabrina Granger, Baptiste Mélès, and Frédéric Santos: "Préserver et rendre identifiables les logiciels de recherche avec Software Heritage". One problem: it's only in French. This post summarizes its key points for non-French speakers, with examples from the exhibition.

A note on the name: Software Heritage's founding documents speak of preserving "the technical and cultural heritage of humanity." In French, heritage is patrimoine — a term that carries connotations of inheritance, of what we receive from and pass to generations. It frames code not just as functional artifact but as something worth transmitting.

This framing has institutional weight. In 2003, UNESCO's Charter on the Preservation of Digital Heritage explicitly listed software among the "born-digital" materials requiring preservation — alongside texts, databases, images, and web pages. The Charter notes that "where resources are 'born digital', there is no other format but the digital object." Unlike a manuscript that can be photographed or a painting that can be reproduced, source code has no analogue original to fall back on. If the digital form is lost, there is nothing else.

In 2016, UNESCO and Inria signed an agreement specifically recognizing Software Heritage's mission. At the signing, François Hollande captured the stakes: "What is expected of us is to be able to control, to be able to transmit, is to be able to put these technologies, this information, these elements that become of the heritage at the service of humanity." The verb transmit — transmettre — is key. Heritage is not just what we keep but what we pass on.

What is Software Heritage?

Software Heritage is a nonprofit initiative launched in 2016 by Inria (French National Institute for Research in Digital Science and Technology) with UNESCO's support. Its mission: collect, preserve, and share all publicly available source code. The archive currently contains over 18 billion unique source files from more than 300 million projects.

The archive addresses a real problem. As the tutorial authors note, URLs in academic publications have a lifespan somewhere between that of a hamster (2 years) and a penguin (15-20 years). Personal websites disappear when people change jobs or retire. Institutional pages break when organizations rename themselves. Even major forges offer no guarantee — remember Google Code?

Software Heritage provides a stable alternative: code archived once remains accessible, with permanent identifiers that won't break.

Why Source Code (Not Executables)?

The tutorial emphasizes a key distinction. Software exists in three forms: source code (human-readable instructions), compilation (the translation process), and executable (machine-readable binary).

Software Heritage archives only source code, not executables. The reason is practical: compilation is largely a one-way process. When source code becomes a binary, comments, variable names, and documentation are stripped away. What remains runs on machines but can't be read or reconstructed by humans. Archiving the executable would preserve the program's function; archiving the source preserves how its creators thought.

The tutorial points to the Apollo guidance computer code as an example. The source contains comments like explanations of why certain routines exist. These are stripped away entirely in the executable. You can explore this yourself in Software Heritage by searching for the repository URL https://github.com/virtualagc/virtualagc.

How Software Heritage Archives Code

The tutorial describes two archiving methods:

Automatic harvesting: Software Heritage regularly crawls major forges (GitHub, GitLab, Bitbucket, etc.) and package archives (npm, PyPI, etc.). Most public open-source code is already archived.

Manual archiving: Anyone can trigger archiving of a public repository using the "Save Code Now" feature. You don't need to be the code's author — you just need the repository URL.

Beyond the code itself, Software Heritage preserves development histories. Every commit is archived with its author, timestamp, and message. This matters for understanding how software evolved. The tutorial cites a 2008 Linux kernel commit by Matthew Wilcox explaining why he simplified a section of code — that reasoning, captured in the commit message, helps future readers understand the codebase.

Gabriel Alcaras's exhibition panel on git-stash makes similar use of commit history. Nanako Shiraishi's original commit from June 30, 2007 includes her explanation: "When my boss has something to show me and I have to update, for some reason I am always in the middle of doing something else." The timestamp tells us it was a Saturday afternoon in Japan. The commit message tells us she wrote it to solve a personal workflow problem. Software Heritage preserves all of this.

Finding Code in the Archive

The tutorial outlines several search strategies depending on what you know:

If you know the project name: Search for the repository in a search engine, find its URL (e.g., https://github.com/torvalds/linux), then enter that URL in Software Heritage's search.

If you have a code snippet: Search for the exact text in a search engine to find which repository contains it, then locate that repository in Software Heritage.

If you have a file: Drag and drop it onto the Software Heritage homepage. The system will tell you if identical content exists in the archive.

If you have a SWHID: Paste it directly into the search bar.

The SWHID Identifier System

This is the core of the tutorial's practical guidance. SWHIDs (SoftWare Hash Identifiers) are permanent identifiers designed specifically for software. Unlike DOIs, which are assigned by a registry, SWHIDs are intrinsic — computed directly from the content through cryptographic hashing. The identifier is tied to the exact content: change one character, and the SWHID changes.

As of April 2025, SWHID is an ISO standard (ISO/IEC 18670).

There are five types, suited to different needs:

The tutorial gives concrete examples. If you're a researcher who used version 1.1.1 of a specific R package, you'd want a release SWHID. If you're writing about a specific algorithm implementation, you'd want a content SWHID pointing to that file, possibly with line numbers.

Obtaining a SWHID: Step by Step

The tutorial walks through the process:

1. Navigate to the code in Software Heritage's archive
2. For files, you can select specific lines by clicking line numbers (shift-click for ranges)
3. Open the "Permalinks" tab on the right side of the interface
4. Choose the appropriate identifier type
5. Optionally check "Add contextual information" to include qualifiers (origin repository, path, etc.)
6. Copy the SWHID

The contextual qualifiers are useful for readers. A bare SWHID like swh:1:cnt:94a9ed024d3859793618152ea559a168bbcbb5e2 points to content but doesn't explain where it came from. A qualified SWHID includes the origin repository, the snapshot, and the file path.

When to Use Which Identifier

The tutorial distinguishes between two main use cases:

For citation (attributing intellectual credit, pointing readers to a version): Use DOI or HAL-ID if available, which link to descriptive metadata. These are like an identity card — they tell you about the software.

For technical verification (ensuring reproducibility, examining specific code): Use SWHID, which points directly to content. These are like fingerprints — they identify the exact artifact.

The two are complementary. A HAL deposit might include a SWHID that points to the precise archived code.

Adding Metadata with CodeMeta

The tutorial's final section covers CodeMeta, a standard for software metadata. A codemeta.json file in a repository provides structured information (authors, license, dependencies, related publications) in a format that bridges different platforms' metadata vocabularies.

The tutorial links to CodeMeta Generator, a web tool for creating these files without writing JSON manually.

Connecting to the Exhibition

Several exhibition panels feature code accessible through Software Heritage:

Stockfish (Mathieu Acher's panel): Browse the repository, navigate to src/position.cpp, find the line PRNG rng(1070372);

Git-stash (Gabriel Alcaras's panel): The original commit can be accessed directly via its SWHID: swh:1:rev:f2c66ed196d1d1410d014e4ee3e2b585936101f5

Wenyan (Baptiste Mélès's panel): Browse the repository

Other panels feature code that required archival work outside Software Heritage — ELIZA's original MAD-SLIP source was transcribed from MIT archive printouts, the Latin American World Model survives as printed code sheets. This distinction matters for thinking about what gets automatically preserved and what requires deliberate recovery.

Resources

• Software Heritage archive: archive.softwareheritage.org
• Save Code Now: archive.softwareheritage.org/save
• SWHID documentation: docs.softwareheritage.org
• Full French tutorial: programminghistorian.org/fr/lecons/preserver-logiciels-recherche
• Exhibition website: www.sourcecode-exhibition.softwareheritage.org

Pierre Depaz, Postdoctoral Researcher, Universität Basel (Exhibition Scientific Committee)

On January 29, 2026, Software Heritage and Inria will open a new exhibition at UNESCO Headquarters in Paris. The "Source Code Exhibition" presents fifteen code examples spanning seventy-five years of computing history. Each is interpreted by a different contributor—historians, artists, developers, activists. The exhibition takes an unusual approach: it treats source code as the central exhibit, not merely as contextual material for hardware or interfaces.

We are part of the organizing team, and we'd like to bring the project to this community: not as a finished argument, but as an invitation to critique, extend, and challenge the choices we've made.

Software Heritage: Preservation as Foundation

This exhibition grows from the work of Software Heritage, a nonprofit launched in 2016 with an ambitious mission: collect, preserve, and share all publicly available source code. Their archive now holds over 18 billion unique source files from more than 300 million projects—a Library of Alexandria for software.

But Software Heritage's vision goes beyond storage. As they put it: "Software in source code form is produced by humans and is understandable by them; as such it is an important part of our heritage that we should not lose." Code carries our technical and scientific knowledge. It mediates access to all our digital information—lose the software, and we lose the capacity to interpret what we've created. Software Heritage recognizes that preserving code is essential for preserving cultural heritage itself.

The exhibition marks Software Heritage's tenth anniversary. It experiments with what becomes possible when preservation meets interpretation. An archive makes code available; an exhibition asks what it means.

The Three Axes

The exhibition organizes its fifteen panels around three overlapping axes:

Source code as historical testimony — how recovered code offers windows into technical and social transformations, from the first programming textbook to ELIZA to XMODEM.

Source code as mirror of society — how code reflects and shapes the cultures that produce it, from a Saturday afternoon git commit to RSA encryption on a protest T-shirt.

Source code as cultural artifact — how code functions as an expressive, aesthetic form, from the thirteen-character fork bomb to programming in classical Chinese.

These aren't rigid categories; most panels resonate across multiple axes.

The Exhibition Online

The physical exhibition space at UNESCO limited us to fifteen panels. We received fifty-one proposals in response to our call for contributions. Selecting among them was difficult. We sought diversity—in time periods, programming languages, geographic origins, and contributors' relationships to code. The final selection reflects those priorities, but also inevitable compromises.

Our hope is that the online version will offer more flexibility. All panel texts, code examples, and contributor bios are available under a Creative Commons license. We aim at revisiting some of the initial proposals and welcome new contributions in the future. We encourage you to spend time with the materials before diving into discussion.

Visit: www.sourcecode-exhibition.softwareheritage.org

Starting the Conversation

Over the coming days, we'll post in-depth code critiques of exhibition panels for discussion, alongside a practical introduction to using Software Heritage as a research tool. But we wanted to open this week by inviting reactions to the exhibition as a whole—its premise, its choices, its gaps.

For instance: how do we best communicate the cultural significance of source code to a broader audience? Many visitors at UNESCO won't have written a line of code. What works, and what gets lost in translation? To paraphrase Benjamin, what is the exhibition value of source code?

Are the three axes we chose—historical testimony, mirror of society, cultural artifact—the right categories? Do they help or hinder interpretation? Are there any other categories that might seem relevant?

And more broadly: what can code learn from existing heritage practices, and what new heritage practices might code require?

We've also posted a companion thread on Software Heritage as a resource for code studies—how to navigate the archive, what's possible with their tools and APIs, and how researchers in this community might use it in their own work.

We look forward to hearing your thoughts—and to exploring the exhibition together.

From the MIT Press:

An anthology of seven decades of English-language outputs from computer generation systems, chronicling the vast history of machine-written texts created long before ChatGPT.

The discussion of computer-generated text has recently reached a fever pitch but largely omits the long history of work in this area—text generation, as it happens, was not invented yesterday in Silicon Valley. This anthology, Output, thoughtfully selected, introduced, and edited by Lillian-Yvonne Bertram and Nick Montfort, aims to correct that omission by gathering seven decades of English-language texts produced by generation systems and software. The outputs span many different types of creative writing and include text generated by research systems, along with reports and utilitarian texts, representing many general advances and experiments in text generation.

Output is first and foremost a collection of outputs to be encountered by readers. In addition to an overall introduction, each of the excerpts is introduced individually and organized by fine-grain genre including conversations, humor, letters, poetry, prose, and sentences. Bibliographic references allow readers to learn more about outputs and systems that intrigue them. Although Output could serve as a reference book, it is designed to be readable and to be read. Purposefully excluded are human–computer collaborations that were conceptually defined but not implemented as a computer system.

This book is part of the new Hardcopy series edited by Nick Montfort and Mary Flanagan, which "features computational artworks that manifest themselves in print" and places itself in "the traditions of artists’ books, bookworks, and publishing as an artistic practice." We have previously discussed Daniel Temkin's Forty-Four Esolangs from the same series.

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 interaction with automated agents.

The publications presented in Hardcopy are themselves the primary artworks. A Hardcopy book is a literary art project, not a work of literary studies, for example. Rather than being catalogs for shows, publications in the series are more aligned with the traditions of artists’ books, bookworks, and publishing as an artistic practice. By presenting innovative and compelling projects, we aim to reveal the diversity of the computational arts —found in algorithmic and software art, electronic literature, digital gaming, the demoscene, livecoding, and generative systems—while also showing connections between historical, current, and emerging practices.

The Output anthology contains a provisional timeline of works (1953-2023) as an appendix, but it is organized instead by 15 topical sections arranged alphabetically: Conversations, Humor, Letters, Novels, Performance, Poetry, Prose, Reporting, Rhetoric Oratory and Lectures, Sentences, Storytelling, Text and Image, Tweets and Microblogging, and Words. One may browse these sections from the table of contents, look up a work by title in the index, or browse years in the timeline and look up the works listed there by their corresponding section heading.

In their introduction, Bertram and Montfort emphasize their principled methods of selection and engagement which eschew creating their own software-based generations in favor of previously available outputs:

In selecting the outputs that follow, although ones of this sort are omitted, we have promiscuously included text from research systems, natural-language generation products and services, and artistic and literary programs. We did not reimplement historical generators to produce the outputs in this book or even download and run programs. The texts here were all previously published in print or online or, in a few cases, were obtained simply by visiting a Web page. Whenever possible, we used the outputs that natural language researchers and author/programmers themselves presented to showcase their work.

For some key selected works appearing in Output, see also this writeup from The MIT Press Reader:

• "The Living History and Surprising Diversity of Computer-Generated Text: selections from 'Output,' an anthology showcasing seven decades of English-language machine-generated texts, long predating ChatGPT."

It includes:

• Random Generation of English Sentences (Victor H. Yngve, 1961)
• Fairy Tale Generator (Joseph E. Grimes, 1963)
• The House of Dust (Alison Knowles, 1967)
• Articulations (Allison Parrish, 2018)
• A Noise Such as a Man Might Make (Milton Läufer, 2018)
• Arria NLG (Arria NLG plc, 2019)

Especially relevant to Critical Code Studies is the editorial emphasis on next steps and "extending your engagement" after reading outputs -- in ways that may be quite familiar to participants in this CCSWG:

We chose to compile this English-language anthology because we knew of no resource like this one. Extending your engagement with the outputs here could be as easy as following a link, either to a working system online or through a bibliographic entry where a paper or article is available. There are already several excellent scholarly articles and books, and even some more popular writing, relevant to the topic of text generation overall. Pursuing those is a great next step for people fascinated with these outputs. Another way to deepen your involvement with text generators is to make one.

"The hard thing for me about these keywords is that at a deeper level all three concepts are historical, all are societal, and all are cultural. [...] Or, to be disciplinary, we might articulate the exhibition value of Code for Historians, Code for Sociologists, and Code for Artists a bit differently because each discipline constitutes knowledge a bit differently."

Jeremy's observation sent me back to the call-for-proposals document, where three example submissions were provided to help potential contributors understand what we were looking for. Each example was deliberately chosen because it mapped cleanly onto one axis: Prolog for historical testimony, Black Perl for cultural artifact, the Brexit protest sign for mirror of society. This was intentional — the goal was to show the diversity of code's place in society and to signal that contributions from varied backgrounds were welcome. We were grateful that this approach worked; the examples helped potential contributors from different fields feel that their code belonged in the exhibition.

Now that the inauguration has passed, I want to reflect on these examples in light of what the final selection revealed. The material constraints of the UNESCO poster format (visible in the attached photograph) shaped what could be shown. Looking back at these three examples alongside the exhibited panels, what do the categories illuminate, and what do they leave in shadow?

EXAMPLE 1

Title: Prolog in Capitals — A Historical Glimpse into its First Programs
Author(s): A. Colmerauer, H. Kanoui, P. Roussel, R. Pasero
Language: Prolog
Year: 1973
Axis: Historical Testimony
Commentary by: Mathilde Fichen

From the call-for-proposals:

"This particular program, designed to decompose a product into its factors, reveals much about the scientific, material and social context of its creation. For instance, the code is written entirely in capital letters, and variables are marked with a star symbol. These features reflect the limitations of the hardware available to the research team, who accessed a remote IBM computer in Grenoble via a teletype machine connected by telephone line—a frugal setup that only permitted uppercase input. The use of the command 'AMEN' to enclose a statement suggests a degree of playfulness among the young team of developers, reflecting their informal working culture."

OPERATEURS ARI TH
   BINAIRE DG + .
   BINAIRE DG . .
AMEN

LIRE AXIOMES
  +T(*A + *B,*C)-T(*A,*A1)-T(*B,*B1)-TPLUS(*A1,*B1,*C)..
  +TPLUS(*A,*B,*A+*B)..
  +TMULT(*A,*B,*A.*B)..
AMEN

DEMONTRER(AXIOMES,DONNEES,RESULT)
ECRIRE(RESULT)
AMEN

The framing emphasizes hardware constraints and material conditions — teletype, remote access, uppercase-only input. But notice what else is present: the "AMEN" command is a joke, a cultural artifact produced by a specific working culture. The "DEMONTRER" command reflects Prolog's origins in theorem-proving, carrying traces of logic and philosophy that exceed the "testimony" frame.

Compare to the exhibition:
Kate Mancey's panel on The Hooter similarly begins with technical description (audio debugging on the Manchester Mark II) but opens onto questions of musical thinking and human-computer relationships. Both examples show how "historical testimony" inevitably carries cultural and social dimensions.

EXAMPLE 2

Title: Black Perl
Author(s): Anonymous (updated by kck for Perl 5.20, 2017)
Language: Perl
Year: 1990 (updated 2017)
Axis: Cultural Artifact
Commentary by: Pierre Depaz

From the call-for-proposals:

"The most obvious feature of this code poem is that it can be read by anyone, including by readers with no previous programming experience: each word is valid both in English and in Perl. A second feature is the abundant use of verbs. Perl belongs to the family of imperative programming languages, which matches a similar grammatical mood in natural languages, the imperative mood."

#!/usr/bin/perl
no warnings;

BEFOREHAND: close door, each window & exit; wait until time.
    open spellbook, study, read (scan, $elect, tell us);
    write it, print the hex while each watches,
        reverse its, length, write, again;
    kill spiders, pop them, chop, split, kill them.
        unlink arms, shift, wait & listen (listening, wait),
        sort the flock (then, warn "the goats" & kill "the sheep");
    kill them, dump qualms, shift moralities,
        values aside, each one;
    die sheep? die to : reverse { the => system
        ( you accept (reject, respect) ) };
    next step,
        kill 'the next sacrifice', each sacrifice,
        wait, redo ritual until "all the spirits are pleased";
    do { it => "as they say" }.
    return last victim; package body;
    exit crypt (time, times & "half a time") & close it,
        select (quickly) & warn your (next victim);
AFTERWARDS: tell nobody.
        wait, wait until time;
    wait until next year, next decade;
        sleep, sleep, die yourself,
            die @last

Pierre's framing emphasizes aesthetics: dual-register words, imperative mood, ambiguity of address. But the 2017 update introduces a historical dimension — the Perl community's ongoing maintenance of Black Perl is itself evidence of how communities sustain cultural artifacts across technical change. Its anonymous 1990 authorship documents a specific moment in USENET culture.

Compare to the exhibition: Baptiste Mélès's panel on Wenyan similarly explores programming as linguistic and cultural expression. Where Wenyan challenges English hegemony by using Classical Chinese syntax, Black Perl exploits the fact that Perl keywords happen to be English words. Both raise questions about the relationship between natural language and programming language — and both have communities that maintain and celebrate them across versions.

EXAMPLE 3

Title: britain.js — Protest Sign at the People's Vote March
Author(s): Unknown (photographed by u/Bronson_AD)
Language: Pseudo-JavaScript
Year: March 23, 2019
Axis: Mirror of Society
Commentary by: Titaÿna Kauffmann

From the call-for-proposals:

"This protest sign exemplifies how programming languages can be repurposed for cultural expression. Rather than instructing a computer, the code serves as a symbolic language for political commentary, similar to a political cartoon. By using JavaScript, the protester specifically targets tech-savvy individuals and younger generations, adding a layer of cultural specificity to the message."

// britain.js
//government servers
while(brexit.isHappening()){
    weAre.screwed();
}

The "mirror of society" framing positions code as reflecting political struggle and programmer identity. But the Reddit circulation revealed something else: community debates about whether the code was "technically accurate" exposed gatekeeping norms about what counts as legitimate code. The sign is also straightforwardly historical testimony — it documents March 23, 2019, a specific moment in British political history.

Compare to the exhibition: Stéphane Bortzmeyer's panel on the RSA T-shirt shows another case where code on fabric performs defiance and community membership. Both examples raise questions about code's circulation beyond screens.

Synthesis: What Escapes the Frame

Jeremy's suggestion that we might reframe the axes disciplinarily — Code for Historians, Code for Sociologists, Code for Artists — clarifies something important. The axes are not properties of the code itself but modes of attention we bring to it. The same snippet can be historical testimony, mirror of society, and cultural artifact depending on what questions we ask.

The call-for-proposals examples were chosen for clarity, and that clarity served contributors well. But looking at the final exhibition — panels like ELIZA, git-stash, or Murs Invisibles — the most compelling code tends to resist clean categorization. These panels invite multiple disciplinary approaches simultaneously.

Discussion Questions

1. Do you find the three thematic axes helpful as interpretive lenses, or do they risk flattening what code can tell us? Would different categories — perhaps disciplinary ones, as Jeremy suggests — open different possibilities?

2. The call examples were chosen for clarity, and several contributors told us the examples helped them feel their code belonged. Is there a tension between pedagogical clarity and interpretive complexity when curating code?

3. For those who work with code as primary source material: how do you decide which frame to foreground? Do you let the code guide you, or do you arrive with questions already formed?

I have more but Eurostar WiFi isn’t what it was…