The Book That Contains a Program

Source Code as a Literary Device

1. The Confession Hidden in Plain Sight

The detective found the program in a notebook beneath the floorboards.

It was only a dozen lines long.

At the top, someone had written a comment:

This program records the truth about what happened that night.

The following lines contained unfamiliar commands, names and numbers. There was no apparent confession, no description of a murder and no reference to the missing woman.

But the detective noticed that the program contained a variable named innocent.

Later, another variable was called witness.

She began to suspect that the programmer had concealed a statement inside the code.

Perhaps the names represented people.

Perhaps the numbers corresponded to dates.

Perhaps the program was an encrypted confession.

Then she noticed something stranger.

The program did not necessarily produce the result suggested by its comments.

If executed, it might tell a different story.

This opening scene is invented. Its notebook, detective and mysterious program are fictional.

But the problem is genuine.

A computer program can be read in at least two ways.

We can examine its words, names, comments and structure as a human-readable text.

Or we can investigate what happens when its instructions are executed.

The two readings may agree.

They may reveal different aspects of the same work.

Or they may contradict each other.

A comment might claim that a program protects information while its operations disclose it.

A variable might be named truth, even though it contains a false statement.

A program might print a declaration of innocence while calculating evidence of guilt.

This creates a distinctive possibility for literature.

The writer can construct a text that speaks simultaneously to a human reader and to a computer.

The reader may understand one meaning by reading the code and discover another by following its execution.

The program can become both a literary object and an event-producing mechanism.

In the previous chapter, we explored the relationship between language and action.

Now we will examine what happens when source code enters literature itself.

Not merely as a description of technology.

Not merely as a collection of mysterious symbols.

But as material that contributes to character, plot, interpretation and sometimes the production of the work.

Ada Lovelace’s published table for computing Bernoulli numbers, 1843. A historical facsimile of an algorithm on the page. Credit: Ada Lovelace. Source. Public domain. Resized; no crop.

2. When Code Is Just Decoration

Imagine opening a science-fiction novel and finding this passage:

The technician examined the monitor.

INITIALISING PRIMARY CORE
MEMORY INTEGRITY: VERIFIED
NEURAL LINK: ACTIVE
AWAITING COMMAND

The display suggests that the machine is technologically sophisticated.

It may create atmosphere.

It may help the reader imagine a particular kind of computer interface.

But the text is not necessarily executable code.

It resembles diagnostic output or an imagined interface.

The novelist could replace it with ordinary prose:

The computer completed its checks and waited for instructions.

The story would lose some visual texture, but the essential event might remain unchanged.

This is one common literary use of code-like material.

It provides atmosphere and signals a technological setting.

A string of hexadecimal numbers, a terminal display or a fragment of programming syntax can make a fictional world appear technically convincing.

Such material may be effective without contributing much to the plot.

The authority of technical appearance

Technical writing often carries an impression of precision.

Numbers, structured labels and unfamiliar symbols can seem authoritative because they resemble the language of engineering.

A novelist can exploit this effect.

Consider the invented phrase:

COGNITIVE MATRIX INTEGRITY: 99.97%

It looks like a scientific measurement.

But what exactly is cognitive matrix integrity?

How is it measured?

What does 99.97% represent?

Without answers, the number may be no more informative than saying that the machine is functioning almost perfectly.

The appearance of technical precision should not be mistaken for an established scientific explanation.

Literature frequently uses invented terminology to create plausible worlds. This is a legitimate artistic technique.

But when evaluating the technical claims of a story, we should distinguish between authentic concepts and fictional decorations.

Does decorative code matter?

Decoration is not necessarily trivial.

A poem's typography can contribute to its meaning.

The appearance of a manuscript can suggest age or authenticity.

A terminal display can establish mood, pacing and cultural setting.

Similarly, code-like text can evoke particular historical periods of computing.

A screen full of numbered BASIC statements suggests a different technological world from a modern Python script or a graphical interface.

The visual form of computing has its own cultural history.

Nevertheless, decorative code does not need to execute.

Its primary purpose is to be seen and interpreted.

This is our first category:

Code as atmosphere: technical-looking text used to establish setting, credibility or mood.

3. Code as Evidence

Now imagine a different detective story.

A researcher has disappeared from a laboratory.

The police discover that the laboratory's automated security system reported an emergency at midnight.

According to the system logs, the emergency doors opened, the lights were disabled and the building was evacuated.

The official explanation is that a software fault caused the incident.

But the detective discovers a short program.

It contains a function named emergency_shutdown.

The function is scheduled to execute at a particular time.

Its instructions reveal that the security system did not malfunction randomly.

Someone deliberately arranged for the emergency procedure to run.

Here, the code is no longer decoration.

It is evidence.

Its behaviour helps establish what happened.

The detective must interpret the program to reconstruct an event.

This resembles the use of letters, diaries, maps and cryptograms in traditional detective fiction.

But source code introduces a special kind of evidence.

A letter may reveal what its author claimed or intended.

A program can provide evidence about what operations were specified.

If the relevant environment is known, the program's behaviour can sometimes be reconstructed through testing or formal reasoning.

Intent is not execution

However, the existence of code does not prove that it was executed.

The program might never have run.

It might have been changed before execution.

Its dependencies might have been unavailable.

It might contain an error preventing the intended action.

And even when the code did execute, its actual behaviour might differ from what the programmer expected.

This is important in both computing and fiction.

A detective cannot simply read a program and assume that its author's comments describe what occurred.

The investigator must distinguish between several kinds of evidence.

None of these sources is automatically infallible.

Logs can be incomplete.

Comments can be outdated.

Configurations may not have been applied.

Source code may differ from the version actually executed.

A careful investigation compares evidence rather than treating one artefact as conclusive.

The literary opportunity

This creates a distinctive kind of mystery.

A character may believe that a program proves something.

Another character may discover that the code was never executed.

A third may reveal that the apparent program was actually a decoy.

The plot can depend on understanding the difference between written instructions and computational events.

In such stories, reading code is an investigative act.

It is analogous to deciphering Poe's cryptogram, but with an additional dimension.

The detective must determine not only what the symbols mean, but what they would do.

4. Code as Character Voice

Authors reveal personality through language.

A cautious character might speak in precise, restrained sentences.

An impatient character might interrupt conversations.

A dishonest narrator might conceal important information while appearing perfectly sincere.

Programming style can provide similar clues.

Consider two fictional programmers.

The first writes:

if door_locked:
    request_permission()

The second writes:

if door_locked:
    force_entry()

Both fragments are invented and rely on fictional functions whose implementations have not been provided.

They are not complete executable programs.

But their names suggest different approaches to the same obstacle.

One programmer appears concerned with authorisation.

The other appears willing to use force.

That interpretation is not guaranteed.

Perhaps force_entry() is the name of a harmless simulation routine. Perhaps request_permission() secretly bypasses the authorisation system.

Still, names influence how human readers interpret code.

The personality of a programmer

Programming involves choices about how to describe a problem.

A programmer selects names for variables and functions.

They decide what comments to write.

They organise code into components.

They choose which assumptions to make explicit.

These decisions can communicate something about how the programmer understands the system.

In fiction, they can also reveal personality.

A meticulous character might write careful comments explaining every decision.

An arrogant character might leave cryptic remarks implying that anyone competent should already understand the program.

A nervous character might surround ordinary operations with unnecessary safeguards.

A secretive character might deliberately use misleading names.

The reader begins interpreting style as evidence of character.

This is analogous to examining someone's handwriting, diary or private correspondence.

But programming style has an additional complication.

Readable code is not necessarily correct code.

And ugly code is not necessarily malicious.

A character's coding habits may reveal personality without establishing technical competence.

Comments as unreliable narration

Programming languages often provide ways to include comments: text intended primarily for human readers rather than execution.

In Python, a comment begins with # outside a string literal.

For example:

# The prisoner has already escaped.
prisoner_escaped = False

The comment claims one thing.

The assignment establishes another.

If later code reads prisoner_escaped, it receives the value False.

Python does not attempt to reconcile the comment with the assignment.

The comment has no authority over the program's behaviour.

This creates an obvious opportunity for literary irony.

The code can become an unreliable narrator.

Its comments may lie.

Its names may conceal.

Its execution may reveal what the prose attempts to disguise.

The author has gained a way to make the reader suspicious of the text itself.

5. The Two Readings of a Program

A conventional poem can be read aloud, silently interpreted or examined for its formal structure.

A program offers an additional possibility.

It can be executed.

This does not mean every program is a poem or every piece of code deserves literary attention.

It means that source code supports different kinds of analysis.

We can examine its human-readable form.

And we can investigate its computational behaviour.

Let us call these the textual reading and the operational reading.

The textual reading

The textual reading examines the program as something written.

We look at names, comments, arrangement, style, metaphors and cultural references.

We may ask why a programmer selected particular words.

We may interpret the emotional or political implications of those choices.

We may notice that a program uses terms such as master, slave, owner or guest, and consider how technical vocabulary reflects historical and social assumptions.

We may also examine typography, indentation and repetition.

A program can possess a recognisable visual form.

The operational reading

The operational reading asks what the code does.

We examine its rules, inputs, state changes and outputs.

We identify conditions and possible execution paths.

We consider whether the behaviour depends on a particular environment.

We test whether the code actually produces the result suggested by its comments.

This reading requires technical understanding.

But it can also reveal literary meaning.

A program that repeatedly prints the same sentence might evoke obsession.

A routine that gradually erases a character's memories could become a formal representation of forgetting.

A program that contains a condition that can never be satisfied might express futility.

These interpretations depend on the relationship between computational behaviour and artistic context.

Neither reading is sufficient alone

Imagine a program named eternal_love().

The name may suggest an emotional theme.

But suppose the function does nothing except return False.

The operational reading complicates the textual reading.

Alternatively, a program may contain no poetic names at all, yet produce extraordinary patterns when executed.

The textual reading might initially find it unremarkable.

The operational reading reveals its artistic significance.

The most interesting code-based literature often depends on the interaction between these readings.

The work rewards readers who ask not only what the program says, but what it causes to happen.

6. The Detective's False Confession

We can now return to the fictional detective from the beginning of the chapter.

She has found a program in a notebook.

Its comments suggest that a witness has confessed.

But its execution tells a different story.

Here is the complete fictional program.

It uses ordinary Python.

It requires no files, network connection, external libraries or system permissions.

It performs only local calculations and prints three lines.

# CASE 17: THE MISSING WITNESS
# The witness confessed before midnight.
# The final report confirms the confession.


witness_confessed = True
evidence_verified = False


def final_report():
    innocent = witness_confessed and evidence_verified
    return innocent


print("Witness confessed:", witness_confessed)
print("Evidence verified:", evidence_verified)
print("Final report:", final_report())

Before examining the result, read the comments and variable names.

The program appears to describe a confession that has been confirmed.

The first comment says the witness confessed.

The second says the final report confirms it.

The variable witness_confessed is set to True.

A hurried reader might conclude that the case is settled.

But the program does something more specific.

It defines a function that combines two Boolean values using and.

The expression is:

witness_confessed and evidence_verified

Both values must be True for the expression to produce True.

In our program:

witness_confessed = True
evidence_verified = False

Therefore:

True and False

evaluates to:

False

The exact output

Running the program produces:

Witness confessed: True
Evidence verified: False
Final report: False

The final report is false.

The program has not confirmed the confession in the sense implied by its comments.

It has calculated that the function's two conditions are not both satisfied.

Trace the program

The comments are not executed.

They do not change the Boolean values.

They do not override the function.

The operational reading contradicts the apparent assurance offered by the comments.

What does this prove?

Within the fictional program, we can establish the exact computational result.

We cannot establish whether the witness really confessed.

We cannot establish whether the evidence was genuinely verified.

The variable names are descriptions chosen by the fictional programmer, not independently authenticated facts.

The statement witness_confessed = True does not prove that a confession occurred in the story's world.

It only assigns a Boolean value.

This distinction is essential.

The program contains claims about events, but its execution does not transform those claims into historical evidence.

A detective would still need to investigate the circumstances surrounding the notebook.

Perhaps the programmer deliberately wrote misleading comments.

Perhaps evidence_verified had not been updated.

Perhaps the function name was chosen carelessly.

Perhaps the entire program was invented to distract investigators.

The code supplies a clue, not a complete solution.

Why this is a literary device

The example can be read as a miniature unreliable narrative.

The comments construct one account.

The computation constructs another.

The reader discovers the contradiction by understanding the rules of execution.

The dramatic effect depends upon technical knowledge.

Without the operational reading, the contradiction may remain invisible.

This is a distinctive possibility for literature containing source code.

The reader can investigate the program rather than merely accept the narrator's explanation of it.

7. What Code Can Reveal That Prose Conceals

A novelist can write a paragraph containing a deliberate contradiction.

For example:

The witness had confessed. There was no doubt about it. Yet the evidence remained unverified.

The contradiction is immediately available to the reader.

Now compare this with our program.

The contradiction is distributed between comments, variables and the operation of a function.

The reader must reconstruct it.

This produces a different experience.

The code creates a small intellectual puzzle.

The reader becomes an investigator.

The meaning emerges through an act of interpretation involving formal rules.

The importance of precision

Programming languages can make certain aspects of a literary puzzle unusually precise.

A Boolean expression has defined behaviour.

A loop executes according to explicit conditions.

A function returns a particular value when given particular inputs.

The author can exploit these properties to create a puzzle with a determinate answer.

But literary meaning still exceeds computation.

Our detective program establishes that final_report() returns False.

It does not tell us whether the programmer was dishonest, incompetent or attempting to warn someone.

That remains a narrative question.

The program supplies evidence.

The story supplies context.

The danger of overinterpretation

Readers may also infer too much from code.

Suppose a variable is named murderer.

A reader might assume that the program identifies a murderer.

But variable names do not guarantee the truth of their contents.

The code might be part of a game.

It might contain test data.

It might represent an accusation rather than a finding.

It might have been written by someone attempting to deceive the investigator.

Technical interpretation must therefore distinguish between the exact behaviour of the program and the assumptions embodied in its names.

This is the same discipline required when reading unreliable narrators in conventional fiction.

The narrator tells us what they believe, remember or wish us to accept.

The reader must decide whether the account deserves trust.

Source code adds another layer.

The program may reveal behaviour that the textual narrator cannot easily control.

8. Nick Montfort and the Literary Possibilities of Code

The relationship between source code and literary art is not merely hypothetical.

Poet, programmer and scholar Nick Montfort has produced substantial work exploring computation as a medium for literature.

His projects frequently make the program itself relevant to understanding the work.

Rather than treating computing as a device for displaying finished poems, Montfort investigates how algorithms, constraints and computational processes can become part of poetic composition.

One important example is Taroko Gorge, originally published in 2009.

The work generates lines of poetry associated with the landscape of Taroko Gorge in Taiwan.

Its language is produced through programmed combinations of textual elements.

The program was originally developed in Python and subsequently presented through HTML and JavaScript.

It became influential partly because other writers adapted its source code to create new generative works. The Electronic Literature Organization's archival record documents its original publication and later preservation.

Reading the poem and reading the program

A reader encountering Taroko Gorge can experience the generated text as poetry.

The lines suggest a landscape through recurring vocabulary, spatial relationships and changing combinations.

But the reader can also investigate the source code.

That reveals something about the poem's construction.

Rather than imagining that every line was individually selected and arranged by the poet, the reader discovers the rules through which lines are produced.

This does not necessarily diminish the work.

It changes the question.

Instead of asking only why the poet selected a particular line, we can ask why the poet selected a particular vocabulary, structure and generative procedure.

The author has written a system capable of producing poetry.

The resulting lines are instances of that system.

A boundary worth preserving

Taroko Gorge primarily belongs to the category of literature generated or governed by executable code.

That is the subject of Part III of this book.

Why discuss it here?

Because its source code is also available for literary examination.

Readers can consider the code as a written artefact and compare it with the generated poem.

The distinction is important.

Code printed inside a conventional novel may contribute to the story without ever being executed.

A generative poem depends on computation to produce its changing textual output.

Taroko Gorge demonstrates how the two modes can overlap.

It provides a documented example in which source code is both the means of producing literary text and an object of critical reading.

9. A Poem Small Enough to Fit in a Program

Montfort's ppg256 series offers an even more concentrated example.

The project consists of minimal poetry generators written in Perl, with each program constrained to 256 characters.

Montfort discussed four such generators in a 2009 paper, presenting their source code alongside an explanation of how they operate and examples of the poetry they produce.

The paper is available directly from his website.

The central artistic constraint is striking.

A program must be extremely short.

Yet it must generate language.

The programmer therefore has to make careful decisions about vocabulary, syntax, repetition and the use of the programming language itself.

The source becomes unusually compact.

Its structure matters because every character consumes part of a limited budget.

The result resembles constrained writing in traditional literature.

A poet might decide to write without using a particular letter.

Another might create a poem containing a fixed number of syllables.

A programmer-poet might decide that the entire generator must fit within a specified number of characters.

In each case, a constraint shapes the resulting work.

What is the poem?

The ppg256 series raises an important question.

Is the poem the program?

Is it the text produced when the program runs?

Or is the literary work the combination of the program, its constraints and the reader's experience of its output?

Different critical approaches may answer differently.

There is no need to pretend that one answer is universally accepted.

The source code is an authored text.

The outputs are generated textual artefacts.

The procedure connecting them is artistically significant.

Together they form a computational literary practice.

Montfort's original paper explicitly encourages readers to obtain and run the programs, then read their output.

This is a major departure from the conventional printed poem.

The work is not exhausted by one fixed sequence of words.

It can produce further sequences through execution.

For our present chapter, the crucial point is that the source code itself remains available for interpretation.

It is not merely an invisible production tool.

The reader can examine how the writing is made.

10. A Single Line That Became a Book

In 2012, MIT Press published a collaboratively authored book with an extraordinary title:

10 PRINT CHR$(205.5+RND(1)); : GOTO 10

The book was written by Nick Montfort and nine collaborators, including Ian Bogost, Mark C. Marino, Michael Mateas and Casey Reas.

Its subject is a one-line BASIC program associated with the Commodore 64.

The program produces a continuing pattern of diagonal characters that creates the appearance of a maze.

The book investigates the program's technical operation, historical setting, aesthetic properties and cultural significance.

It treats a very small piece of software as something worthy of sustained critical interpretation.

The publisher describes the project as an exploration of the cultural context of computing through a single line of code.

The significance of the title

The title is itself source code.

To a reader unfamiliar with BASIC, it may appear to be an obscure formula.

To someone familiar with the language and machine, it describes a process involving printing characters, randomness and repetition.

The program has visual consequences when executed in the intended environment.

Its output can be understood as a form of generative visual art.

But the book's argument goes further.

Code is not merely an instrument.

It is also a cultural object.

A program is written by people working within particular technological environments.

It reflects available hardware, programming languages, conventions and creative possibilities.

A single line can therefore reveal an entire history of computing practices.

Why the platform matters

The Commodore 64 had particular character graphics and conventions that shaped the program's behaviour.

The code depends on those characteristics.

Simply placing the text into an unrelated modern programming language would not produce the same result.

This illustrates a fundamental property of executable literature.

The relationship between source code and output depends upon the execution environment.

A program is not guaranteed to behave identically across every machine.

Programming languages evolve.

Hardware changes.

Libraries disappear.

Operating systems impose different constraints.

For printed literature, the survival of the words is often sufficient to preserve much of the work.

For computational literature, preserving the source code may not be enough.

The work may also depend on particular software or hardware behaviour.

This creates a challenge for literary history.

How do we preserve works whose full experience requires obsolete technology?

The question will become increasingly important in Part III.

11. Critical Code Studies: Reading the Instructions

The examination of code as a cultural and literary text belongs partly to an area of scholarship known as critical code studies.

The field investigates how source code can be interpreted in relation to its social, historical, political and cultural context.

Its concerns extend beyond literary art.

A program may contain assumptions about users, institutions, categories or acceptable behaviour.

A naming convention may reflect a particular history.

A technical design may embody choices about who is permitted to act and who is excluded.

Critical analysis asks what those decisions reveal.

This does not mean that source code should be interpreted without understanding how it works.

On the contrary, technical knowledge can strengthen cultural interpretation.

A reader who does not know what an instruction does may misunderstand its significance.

A reader who understands only the execution may overlook the historical assumptions behind its design.

The two kinds of knowledge complement each other.

Code as a document of its time

Consider an old computer program written for a machine with very little memory.

The programmer may use unusually compact names, minimise stored information and avoid expensive operations.

Those decisions reflect technical constraints.

But they may also reveal something about the period's computing culture.

A modern programmer might find the code difficult to read.

A historian might recognise that it was designed for hardware on which every byte mattered.

The same source code can therefore support several interpretations.

As engineering, it is a solution to a computational problem.

As history, it records a particular technological environment.

As cultural material, it reveals practices and assumptions.

And, in some cases, as literature, it becomes part of an artistic work.

The danger of treating all code as poetry

Not every program is intended as literature.

A payroll system may contain interesting variable names and complex logic without becoming a poem.

A database query may possess an elegant structure without being a short story.

A security routine may be important without having an artistic purpose.

Critical interpretation should not erase these distinctions.

The question is not whether every piece of source code secretly belongs to literature.

It is whether source code can sometimes contribute to literary meaning, or become an object of literary analysis, in ways that deserve serious attention.

The answer is clearly yes.

But the strength of the claim depends on the particular work.

Some programs are aesthetically designed.

Some are culturally revealing.

Some are included within fiction.

And some are primarily tools whose literary significance is limited.

The categories overlap without becoming identical.

12. The Book With Two Endings

Imagine a novel containing a program on its final page.

The surrounding prose tells us that a spacecraft's artificial intelligence has decided to sacrifice itself to save its passengers.

The program appears to describe its final decision.

A casual reader sees a comment:

The system will shut down permanently.

The code contains a function named final_shutdown.

The scene appears tragic.

But a technically knowledgeable reader notices that the function does not actually terminate the simulated intelligence.

Instead, it changes a status flag and creates a continuation state.

The code would produce evidence that some part of the system remains active.

The book has acquired a second interpretation.

One reader encounters a story of sacrifice.

Another discovers a suggestion of survival.

This is an invented literary example, not a description of a published novel.

Its purpose is to illustrate the artistic possibilities of executable evidence.

Two meanings, one object

The program possesses a human-readable surface.

Its comments and names support the apparent ending.

Its operations support another.

The difference becomes a narrative device.

Unlike a conventional hidden message, the secret does not necessarily require a cipher.

It may be visible in plain sight to someone who understands the programming language.

The code becomes a specialised form of literary literacy.

A reader familiar with programming can recognise implications that another reader may miss.

This raises an interesting artistic problem.

Should a novel require technical expertise to reveal its full meaning?

Some literature already demands specialised knowledge.

Historical novels may contain references understood more fully by readers familiar with the period.

Poetry may depend upon classical mythology, theology or linguistic detail.

Mathematical fiction may contain structures that reward readers capable of recognising them.

Source code introduces another possible layer.

But an author should consider whether the technical puzzle enriches the work or merely excludes readers unnecessarily.

A good code-based literary device can reward specialist understanding while preserving a meaningful experience for other readers.

The code should contribute to the work rather than function as an arbitrary examination question.

13. When the Reader Becomes a Programmer

There is a further possibility.

What if readers are invited to modify the code?

A printed book containing a program can invite readers to type it into a computer.

A digital work may allow them to inspect its source.

A generative poem may encourage readers to replace words and observe the results.

At that point, reading begins to resemble programming.

The reader is not merely interpreting an existing text.

They may be altering the rules that produce it.

This raises questions about authorship.

Suppose a writer creates a poem generator.

A reader changes its vocabulary.

Another reader modifies its structure.

A third produces a completely different work using the same underlying procedure.

Who is responsible for the resulting text?

The original programmer?

The person who modified the source?

The system that generated the output?

Or some combination?

The answer depends partly on what we mean by authorship.

Legal authorship, creative contribution and technical causation are not identical.

A computer program can generate a particular sentence without being a conscious author.

A human programmer can design a generative system without choosing every sentence it produces.

A reader can contribute creatively by changing the system.

These activities may all influence the final artefact.

The boundary between Parts II and III

This is where our present category begins to merge with the next.

In Part II, we have examined literature containing source code or using it as a literary device.

The code may be printed within a story, presented as evidence or analysed as text.

In Part III, we will examine works whose production or presentation depends directly on executable rules.

The distinction can be expressed simply.

Literature containing code asks what the code contributes to the written work.

Literature generated or governed by code asks how computation shapes the work that readers encounter.

A literary artefact can belong to both categories.

Taroko Gorge is a clear example because its program produces poetry and can also be read as a written artefact.

The 10 PRINT book examines executable source code as a cultural text, while the underlying program produces visual output.

The ppg256 projects treat compact programs as authored generators whose output becomes part of the literary experience.

These examples show that the boundary is not a wall.

It is a useful distinction between different relationships among author, text, machine and reader.

14. The Last Line of Code

Return once more to the detective and the notebook.

She has discovered that the program's comments claim the witness confessed.

The code confirms only that a variable has been set to True.

Another variable records that the evidence has not been verified.

The final report returns False.

The detective now possesses a clue.

But she also possesses a warning.

The program's apparent narrative and its actual behaviour are not the same.

Its comments may express an intention.

Its names may imply facts.

Its execution follows formal rules.

And none of these automatically establishes what happened outside the program.

To solve the mystery, she must combine technical interpretation with ordinary investigation.

She must discover who wrote the code, when it was written, whether it was executed and why its comments conflict with its operations.

The notebook is not merely a confession.

It is an artefact requiring interpretation.

This is the essential lesson of source code as a literary device.

A program can be read.

It can be executed.

It can reveal intentions, assumptions and contradictions.

It can contribute to character and plot.

And under suitable circumstances, its behaviour can create a second narrative alongside the one presented in prose.

The programmer has written instructions for a machine.

The novelist has placed those instructions within a meaningful fictional context.

The reader must understand both.

The end of the written machine

This chapter completes Part II of The Literary Machine.

We began by examining secret messages and the mathematical representation of information.

We then compared the structures of programs and stories.

Next, we investigated the relationship between language and action.

Finally, we have considered code as something that can be read, interpreted and executed within literature.

The progression has brought us to a threshold.

So far, the book has usually remained the primary literary object.

The code has appeared within it, alongside it or as something to be examined.

But what if the code becomes the primary creative mechanism?

What if the author writes no fixed sequence of verses, but instead constructs a system capable of producing thousands, millions or trillions of different poems?

What if the text changes whenever it is read?

What if there is no single definitive version?

At that point, the literary work can no longer be understood only as a collection of completed sentences.

It becomes a set of possibilities.

The author creates rules.

The machine produces combinations.

And the reader encounters one possible expression of the work.

The next stage of literary history begins when the book ceases to contain a program and begins to behave like one.

Questions to Take Away

1. What distinguishes code used as visual decoration from code that contributes essential evidence to a story?
2. If a program's comments describe one outcome but its execution produces another, which account should a reader trust? What additional evidence might be required?
3. Can variable names reveal something meaningful about a fictional programmer's personality, even when those names are misleading?
4. How does reading a program differ from executing it? Can either activity provide a complete interpretation of a code-based literary work?
5. In Nick Montfort's ppg256 series, should we regard the program, its generated output or the combination of both as the literary work?
6. Why does the execution environment matter when preserving computational literature?
7. How might an author use a program to conceal an alternative ending without using conventional encryption?
8. If readers can modify a literary program and generate new text, how does that affect our understanding of authorship?
9. Does technical correctness make a program artistically successful? Could technically defective code still possess literary significance?
10. Can software be both a functioning computational artefact and a meaningful work of literature?

A Small Experiment: The Unreliable Program

Return to the detective program in Section 6.

Its comments suggest that the witness's confession has been confirmed, but its final report returns False.

Your task is to investigate how the program's apparent narrative changes when its data or comments change.

Step 1: Predict a different result

Start with the original assignments:

witness_confessed = True
evidence_verified = False

Now change the second assignment:

evidence_verified = True

What will the program print?

Step 2: Examine the worked result

The function still contains:

innocent = witness_confessed and evidence_verified
return innocent

Both variables are now True.

Therefore:

True and True

evaluates to True.

The complete output becomes:

Witness confessed: True
Evidence verified: True
Final report: True

The function returns a different result even though none of the comments have changed.

Step 3: Change the narrative but not the computation

Restore the original values:

witness_confessed = True
evidence_verified = False

Now replace the comment:

# The witness confessed before midnight.

with:

# The witness has never admitted anything.

Run the program again.

The output remains:

Witness confessed: True
Evidence verified: False
Final report: False

Changing the comment has affected the program's human-readable narrative, but not its execution.

Step 4: Examine all possible outcomes

The function uses Boolean AND.

Its complete truth table is:

Notice that the function's internal variable is named innocent.

But its calculation does not logically establish innocence.

It merely determines whether two Boolean values are both true.

The name is potentially misleading.

Step 5: Become the detective

Write two short paragraphs explaining the program.

The first should describe what a non-programming investigator might believe after reading its comments.

The second should explain what the program actually calculates and why that result does not establish the truth of the underlying fictional events.

What this experiment demonstrates: Source code can support competing interpretations because comments, names, operational behaviour and real-world evidence are different things. A literary author can exploit those differences deliberately.

Further Reading

Original Computational Literature

Nick Montfort — Taroko Gorge (2009)

A documented generative poem whose changing text is produced by a program. The author's site also provides links to adaptations by other writers.

Read the original work — Nick Montfort

Electronic Literature Organization — Archival record

Nick Montfort — ppg256 (2007 onward)

A series of minimal Perl poetry generators exploring the relationship between compact source code and continually produced language.

Original programs — Nick Montfort

The ppg256 Series of Minimal Poetry Generators — Montfort's 2009 paper

Nick Montfort and nine collaborators — 10 PRINT CHR$(205.5+RND(1)); : GOTO 10 (2012)

A book-length examination of a one-line Commodore 64 BASIC program as a technical, historical and cultural artefact.

MIT Press — Official book page

Authors' project and open-access PDF

Mark C. Marino — Critical Code Studies (2006)

Programming and Interpretation

Python Software Foundation — Python Language Reference

Official explanations of Python's execution model, names, expressions, statements and comments.

Python Language Reference

Electronic Literature Organization — Electronic Literature Collection

A curated collection of electronic literary works, including pieces that depend on programming, interaction and computational processes.

Electronic Literature Collection

Suggested Reading Order

Begin with Montfort's Taroko Gorge. Read the generated poem before examining its source code.

Next, investigate ppg256. Consider how its strict programming constraints influence its language and form.

Finally, approach 10 PRINT as an extended example of close reading applied to computer code.

The central question throughout is not whether programs resemble conventional poems.

It is how their textual form, operational behaviour and cultural context can combine to produce literary significance.

Up Next — A Hundred Trillion Poems

Part III — The Executable Book

Combinatorial Literature Before Electronic Computers

We have reached the boundary between two ways of writing.

In Part II, code appeared within literature as decoration, evidence, characterisation and executable text.

But what happens when the author stops composing individual sentences and instead constructs rules for generating them?

Long before modern computers, writers experimented with mechanical and mathematical methods of producing literature.

They discovered that a comparatively small collection of carefully organised words could produce an astonishing number of possible texts.

Raymond Queneau's combinatorial sonnet book is our next case study. We will examine its interchangeable lines and its extraordinary space of possibilities.

The mathematics is straightforward.

There are ten choices for each of fourteen lines.

The total number of combinations is:

10¹⁴ = 100,000,000,000,000

One hundred trillion possible sonnets.

The book is not merely a collection of poems.

It is a mechanism for producing poems.

And it achieves this without requiring an electronic computer.

Chapter Nine will examine Queneau's extraordinary invention, the history of combinatorial writing and the mathematical principles that allow simple literary structures to generate enormous spaces of possibility.

We will ask whether every possible combination should count as a poem, whether the reader becomes a co-author through selection and why generating possibilities is different from creating meaning.

The central question changes once more.

What happens when an author writes not a single work, but the rules from which an almost unimaginable number of works can emerge?