# The Programmer as Author Why Computer Programs Resemble Stories ## 1. The Door at the End of the Corridor The detective reached the end of the corridor shortly before midnight. There was a locked door, an iron key hanging from a hook and a narrow window overlooking the courtyard. Beyond the door, someone was calling for help. She took the key, examined the lock and tried to open it. The door remained closed. From somewhere behind her came the sound of footsteps. She had very little time. This is the beginning of a story. It introduces a character, establishes a situation and creates a problem. But suppose we stop writing prose and begin describing the scene as a computer program. We give the detective a name: Mara. We establish some facts about the world. The door is locked. Mara does not possess the key. Someone is trapped beyond the door. The corridor will become dangerous after midnight. We then define rules. Mara can take the key if she is near it. She can unlock the door if she possesses the key. She can rescue the prisoner if the door is open. Suddenly, the scene looks less like a conventional short story and more like a small computer simulation. Both versions describe a fictional world. Both contain objects, characters, relationships and events. But there is a crucial difference. The story tells us what happens. The program defines operations determining what happens when specified conditions occur. One presents a particular sequence of events. The other can describe a system capable of producing multiple sequences. This distinction opens a surprisingly rich connection between literature and computing. A programmer, like a novelist, must construct a coherent world. A character, like a software object, possesses characteristics that may change over time. A plot, like an executing program, develops through sequences of events and relationships between causes and consequences. Yet we must be careful. A story is not simply a program written in ordinary language, and a program is not automatically a story. The similarities are useful because they illuminate how both activities organise complexity. The differences matter because literature and software are designed to achieve different things. To understand their relationship, we need to examine the basic building blocks of computation. We will do so by following Mara through the locked corridor. ![Margaret Hamilton beside printed Apollo guidance software listings, 1969. Restored historical photograph.](images/hamilton-listings.jpg) Margaret Hamilton beside printed Apollo guidance software listings, 1969. Restored historical photograph. Credit: Adam Cuerden (restoration). [Source](https://commons.wikimedia.org/wiki/File:Margaret_Hamilton_-_restoration.jpg). [Public domain](https://creativecommons.org/publicdomain/mark/1.0/). Resized; no crop. ## 2. Sequence: The Order of Events The simplest element of a computer program is sequence. An instruction is followed by another instruction, and then another. Consider: ```python print("Mara enters the corridor.") print("She sees a locked door.") print("She hears someone calling for help.") ``` When Python executes these statements in order, the output is: ```text Mara enters the corridor. She sees a locked door. She hears someone calling for help. ``` This resembles the simplest form of storytelling. An event happens. Another event follows. Then something else occurs. In his 1927 lectures collected as Aspects of the Novel, E. M. Forster distinguished between a story organised through the sequence of events and a plot concerned with the causal relationships among them. The distinction is fundamental. Consider these statements: The detective entered the room. The clock struck midnight. The prisoner screamed. They establish a sequence. But we do not yet know whether the events are causally connected. Perhaps the prisoner screamed because the clock activated a hidden mechanism. Perhaps the scream was unrelated. Perhaps the detective's arrival caused the prisoner to panic. A novelist can deliberately leave those relationships uncertain. A computer program, by contrast, has an operational interpretation defined by its language and execution environment. If one instruction modifies information that another instruction uses, the relationship can be made explicit. For example: ```python door_locked = True door_locked = False if not door_locked: print("The door opens.") ``` The program prints: ```text The door opens. ``` The result follows from the value assigned to `door_locked` and the condition being evaluated. There is no mystery about why the branch executes. The computer does not interpret the dramatic significance of opening the door. It evaluates a condition. This reveals an important difference. Narrative sequence organises events for a reader. Program sequence organises operations for a machine. Sometimes the two correspond closely. But literary events need not be presented in chronological order. A novel may begin with a murder, return to the previous morning and reveal the cause only near the end. The order in which a reader discovers events can differ from the order in which those events occurred within the fictional world. Programs can also implement histories, reverse operations and reconstruct previous states, but their execution must follow the operational rules of the programming language. A novelist controls the order of revelation. A programmer controls the rules of execution. Both can use sequence to produce surprise, but they work with different kinds of causation. ## 3. Choice: The Road Not Taken Our detective encounters a decision. She can take the key or attempt to force the door. A conventional story might describe her choice: Mara reached for the key, hesitated, and then pulled it from the hook. The author has selected one outcome. But a program can represent several possible outcomes. ```python has_key = True if has_key: print("Mara unlocks the door.") else: print("Mara searches for another entrance.") ``` The result depends on the value of `has_key`. This is called conditional execution. The program evaluates a condition and selects which instructions to execute. In Python, `if` and `else` provide a straightforward way to express such decisions. The similarity with fiction is immediate. Stories frequently involve choices. A character decides whether to tell the truth, escape danger, trust a stranger or open a forbidden door. Different decisions could lead to different events. But the resemblance contains an important limitation. A fictional character may make a choice for complicated reasons involving memory, emotion, conflicting loyalties or incomplete understanding. The Python variable `has_key` contains none of those experiences. It merely records a value. The conditional statement does not deliberate. It follows a rule. ### Branching narratives Interactive fiction brings the two approaches closer together. A reader might be presented with a choice: Take the key. Break the window. Return to the staircase. Each decision leads to another passage. This creates a branching structure. A conventional novel generally presents one reading path, although its chronology and interpretation may be complicated. A branching story defines several possible paths. A computer program can select among them according to reader input. However, the existence of choices does not guarantee meaningful agency. Suppose every option ultimately leads to the same ending. The reader has made selections, but those selections have had little influence over the outcome. This is a problem familiar to designers of interactive narratives. A choice is dramatically meaningful when it changes something the reader considers important. That might be the outcome, a relationship, a character's knowledge or the reader's understanding of the story. An effective program must execute the specified branch. An effective story must make the branch matter. Those are related but different requirements. ## 4. Repetition: The Corridor That Never Ends Literature frequently uses repetition. A refrain returns in a poem. A character repeatedly makes the same mistake. A detective revisits the same evidence until an overlooked detail becomes significant. A myth may describe a hero condemned to perform the same task forever. Programming also uses repetition, but for a more precise purpose. A loop allows instructions to be executed repeatedly according to defined rules. Imagine Mara attempting to open a mechanical lock. She has three numbered keys. Only one works. A program can test them in sequence. ```python keys = [1, 2, 3] correct_key = 2 for key in keys: if key == correct_key: print("The door opens.") break ``` The program examines the first key and discovers that it does not match. It then examines the second. The second key matches, so the program prints the message and exits the loop. The third key is never tested. A loop allows us to describe repeated activity compactly. Without it, we might need to write separate instructions for every attempt. This becomes especially important when the number of repetitions is large. A program might examine millions of records, process thousands of images or simulate hundreds of possible outcomes. A writer can likewise describe repeated actions without narrating every occurrence. Mara tried the keys one after another until the second turned in the lock. The sentence compresses a sequence of actions into a single meaningful event. But the literary compression and computational loop are different. The prose leaves many details unspecified. How quickly did Mara try the keys? Did she hesitate? Was she frightened? Did the first key become stuck? The program supplies a precise rule for selecting and testing values, but it does not contain those dramatic details. ### When repetition becomes dangerous Loops can also fail. Suppose we write: ```python while True: print("Mara searches the corridor.") ``` The condition is always true. Unless execution is externally interrupted, the program continues printing the sentence indefinitely. This is an infinite loop. Infinite loops can be intentional, as in a service designed to continue operating, or accidental, as when a programmer forgets to provide an exit condition. Literature has its own fascination with repetition without resolution. A character may be trapped in a repeating day. A curse may require the same task to be performed endlessly. A bureaucratic process may continually return an applicant to the beginning. The analogy is useful, but the consequences differ. In software, an unintended infinite loop is typically a technical defect. In literature, endless repetition may be the central artistic achievement. ![Three fixed instructions change Mara’s key, door and rescue state; a trace records changes while a story supplies their significance.](images/story-state-trace.svg) :::lab rescue ## 5. State: The Memory of a Fictional World A program needs to keep track of what has changed. If Mara collects a key, the system must remember that she possesses it. If the door is unlocked, later actions must recognise that the door is no longer locked. The information describing a system at a particular moment is called its state. For our fictional world, we might define: ```python world = { "has_key": False, "door_locked": True, "prisoner_rescued": False, "time": 0 } ``` The dictionary records four properties. At the beginning, Mara has no key, the door is locked, the prisoner has not been rescued and the fictional clock reads zero. When Mara collects the key, one property changes. When she unlocks the door, another changes. This is called a state transition. A simple mathematical representation is: Sₜ₊₁ = F(Sₜ, aₜ) Here: - Sₜ is the current state. - aₜ is an action. - F is a rule describing the effect of the action. - Sₜ₊₁ is the resulting state. For example: F(door locked and has key, unlock) might produce a state in which the door is unlocked. ### The literary connection A fictional world also has a state. The detective possesses certain information. The murderer knows whether the detective is approaching the truth. A witness has told a lie. A door is locked. A letter remains unread. As a story progresses, these conditions change. Some changes are physical. Others are psychological or social. A character may learn that a trusted friend has betrayed them. Nothing visible in the room needs to change, yet the fictional world has been transformed. The character's beliefs, intentions and relationships are now different. In a computer simulation, we would need to represent relevant changes explicitly if subsequent rules depended upon them. A novelist can rely on the reader to infer much more. The reader remembers earlier events and interprets their significance. A computer program remembers whatever information its implementation preserves. This distinction becomes especially important when designing interactive fiction. If a character has already discovered a secret, the program must avoid presenting later dialogue as though the secret were still unknown. The software must maintain narrative consistency. A failure to do so resembles a continuity error in a novel. But in a program, the error may arise from an incorrect state update or an incomplete condition. ## 6. Building a Small Executable Story We can now combine sequence, choice, repetition and state into one small program. Our fictional world has fixed rules. Mara enters a corridor. The key hangs on a hook. The door is locked. The prisoner is behind it. Mara has three turns before the corridor becomes unsafe. Taking the key costs one turn. Unlocking the door costs one turn. Rescuing the prisoner costs one turn. She must act in the correct order. Here is the complete program. ```python world = { "has_key": False, "door_locked": True, "prisoner_rescued": False, "time": 0 } def take_key(state): state["has_key"] = True state["time"] += 1 def unlock_door(state): if state["has_key"] and state["door_locked"]: state["door_locked"] = False state["time"] += 1 def rescue_prisoner(state): if not state["door_locked"] and state["time"] < 3: state["prisoner_rescued"] = True state["time"] += 1 take_key(world) unlock_door(world) rescue_prisoner(world) print(world["prisoner_rescued"]) print(world["time"]) ``` The output is: ```text True 3 ``` Mara successfully rescues the prisoner. The rescue action begins when the fictional time is 2, satisfying the condition that it must begin before turn 3. After the action, time advances to 3. This is a deliberately small model. It has no graphics, no user input and no independent artificial intelligence. Its purpose is to illustrate how a fictional situation can be represented through executable rules. ### Tracing the execution A programmer can examine the program one operation at a time. This is called tracing. | Stage | Has key | Door locked | Prisoner rescued | Time | | --- | --- | --- | --- | --- | | Initial state | False | True | False | 0 | | After `take_key()` | True | True | False | 1 | | After `unlock_door()` | True | False | False | 2 | | After `rescue_prisoner()` | True | False | True | 3 | The final state follows directly from the operations. Notice that the program describes a very narrow world. Mara cannot break the door. She cannot talk to the prisoner. She cannot climb through the window. She cannot decide to abandon the rescue. Those actions do not exist in the model. This reveals an important limitation of computational fiction. A programmed fictional world contains only the possibilities represented by its design and execution environment. A reader of conventional prose may imagine countless alternatives. A player interacting with a computerised world can normally perform only actions that the system recognises. The author's task changes accordingly. Instead of describing every event, the author-programmer designs the rules governing possible events. ## 7. Functions: Giving Names to Actions Our program contains three functions: `take_key()` `unlock_door()` `rescue_prisoner()` A function is a named unit of program behaviour that can be invoked when required. Functions may receive information, perform operations and return results. They help programmers organise complicated systems into smaller, comprehensible parts. The official Python tutorial introduces functions as reusable blocks of code defined using the `def` statement. In our fictional example, the function names also possess narrative meaning. `take_key()` describes an action a character performs. `unlock_door()` changes the state of the environment. `rescue_prisoner()` represents the story's immediate objective. This makes the code relatively easy to read. But consider a different function: ```python def change_mind(character): character["trust"] = 0 ``` It might represent a character losing trust in someone. Technically, the function is straightforward. But as literature, it is unsatisfying. Why did the character lose trust? What happened? Was there a betrayal? A misunderstanding? A revelation? The function specifies a change without explaining its human significance. A novelist must make the transformation believable. A programmer must make it executable. An interactive-fiction designer may need to do both. ### Abstraction Functions illustrate a central programming technique called abstraction. We give a complex operation a name and use that name without repeating every internal detail. A story also employs abstraction. A sentence might say: The detective searched the room. The reader understands that this involves numerous possible actions: examining drawers, inspecting shelves, looking beneath furniture and noticing unusual objects. The writer does not need to describe every movement. But the reasons for abstraction differ. In programming, abstraction helps manage complexity, reuse behaviour and clarify interfaces. In literature, abstraction helps control pace, attention and emphasis. The novelist may deliberately omit routine actions so that a significant discovery receives greater attention. A programmer may encapsulate routine operations so that other parts of the system can invoke them reliably. Both are choosing what to make explicit. But only the program must satisfy the requirements of execution. ## 8. Debugging: The Detective Work of Programming Imagine that Mara has taken the key and unlocked the door. Nevertheless, the prisoner is not rescued. The program reports: ```text False 3 ``` Something has gone wrong. We must investigate. This is debugging: the process of identifying, understanding and correcting defects in software. The word bug has a history predating electronic computers, although a famous 1947 incident involving a moth found in a Harvard Mark II relay helped popularise the association between insects and computer faults. The original logbook is preserved in the Smithsonian's collections. Our fictional program contains several possible sources of failure. Perhaps the key was never collected. Perhaps the unlocking condition was incorrect. Perhaps the rescue was attempted too late. Perhaps the program recorded the rescue in the wrong variable. A programmer can inspect the state after each operation. The trace table becomes evidence. This resembles detective work. The programmer begins with an unexpected outcome and searches for the cause. ### A deliberate bug Consider this incorrect version of the unlocking function: ```python def unlock_door(state): if state["has_key"] and state["door_locked"]: state["door_locked"] = True state["time"] += 1 ``` The condition is correct. Mara has the key. The door is locked. But the function assigns `True` to `door_locked`, leaving the door locked. When the rescue is attempted, the condition fails. The prisoner remains trapped. The defect is a single incorrect value. Changing it to `False` restores the intended behaviour. ### Plot holes and software bugs A plot hole is not necessarily a software bug. Suppose a detective story establishes that its protagonist has no key, then suddenly allows her to open a locked door without explanation. Readers may recognise an inconsistency. The author has violated expectations established by the fictional world. A program may contain a comparable defect if it allows an action that should be prohibited. But literature also permits ambiguity, unreliable narrators and unexplained events. An apparent contradiction may be deliberate. A detective might have secretly copied the key. The narrator might have concealed that information. A program can represent unreliable information too, but its execution still follows defined rules. The difference is between an inconsistency in the fictional account and a failure of the implemented computational system. Good debugging involves determining whether the observed behaviour differs from the intended specification. Good literary criticism asks whether an apparent inconsistency damages the work or contributes to its meaning. The activities resemble each other, but they do not use identical standards of correctness. ## 9. When the Rules Produce an Unexpected Story Our corridor program is deterministic. Given the same initial state and the same sequence of actions, it produces the same result. But what if Mara can choose among several actions? What if an unseen guard moves through the building? What if the prisoner can provide information? What if a key sometimes breaks? The number of possible outcomes grows. A writer might describe one sequence. A program can define a space of possible sequences. For example, suppose Mara has three actions available at each turn. After one turn, there are three possible action sequences. After two turns, there are: 3² = 9 After five turns: 3⁵ = 243 And after ten turns: 3¹⁰ = 59,049 These counts assume three choices remain available at every turn and that we count action sequences rather than distinct resulting states. In a real simulation, some actions might be unavailable, and different sequences could lead to the same state. Nevertheless, the example demonstrates how quickly possibilities multiply. This is combinatorial growth. It explains why interactive stories become difficult to design when every choice creates substantially different consequences. A conventional novelist can concentrate on one selected sequence of events. An interactive-fiction author may need to consider many possible sequences. A programmer can help manage this complexity by defining reusable rules. But the rules may produce combinations that the author did not anticipate. For example, a character might acquire an object earlier than expected. A conversation might occur after an important character has died. Two independently reasonable rules might combine to produce an absurd outcome. The system may be operating correctly according to its individual instructions while generating a narratively incoherent situation. This is where programming and literary design meet. The author must decide whether unexpected outcomes are interesting possibilities or defects that need to be prevented. Some interactive works deliberately embrace emergence. They allow complex stories to arise from relatively simple rules. Others use carefully controlled branching structures to preserve dramatic coherence. Neither approach is inherently superior. They offer different relationships between author, system and reader. ## 10. The Program That Explains Itself In 1984, the computer scientist Donald Knuth published an influential paper titled Literate Programming. Knuth proposed a different way of organising software. Instead of treating explanatory documentation as something added after the program was written, he argued that programs could be composed primarily for human understanding. His WEB system allowed programmers to interleave explanatory prose with program fragments and organise the material in a form suited to readers, while tools could assemble the instructions required for compilation. The idea is important because programmers work with two audiences. One audience is the computer. The computer requires instructions expressed according to the language's formal rules. The other audience is human. A future programmer needs to understand the purpose, assumptions and organisation of the software. The computer does not need a beautiful explanation of why an algorithm was chosen. A human reader may need precisely that explanation. ### Two ways of reading a program Consider our corridor simulation. A computer processes instructions according to Python's execution rules. A human reader may ask: Why does Mara have three turns? Why is rescuing the prisoner the objective? Why must the key be collected before the door can open? Why is there no alternative escape route? These questions concern the design of the fictional world. They are not answered merely by knowing that the code executes successfully. Literate programming attempts to bring purpose and implementation into a unified presentation. It does not automatically transform every program into a work of literary art. The term literate concerns the intelligibility and organisation of software. Nevertheless, Knuth's proposal establishes an important historical connection between programming and literary composition. It treats explanation as a central part of the programming process. ### A program as an argument A well-written program can communicate a line of reasoning. It begins with a problem. It introduces concepts. It establishes relationships. It presents a method. It demonstrates how the method produces a result. This resembles the structure of an explanatory essay. The difference is that the computational portion must also satisfy precise operational constraints. A literary argument may persuade through metaphor, evidence and interpretation. A program must produce defined behaviour when executed. The strongest combination of the two makes both the reasoning and the execution understandable. ## 11. The Author, the Reader and the Machine We can now identify three distinct roles within computational literature. The author designs the fictional world, its language, rules and possible events. The machine executes the implemented rules and presents results. The reader interprets the resulting material and may sometimes influence what happens next. In a conventional printed novel, the author's text is normally fixed before the reader encounters it. The reader can interpret, imagine and reconsider events, but cannot ordinarily change the printed words. In an interactive program, the reader may provide inputs that affect the sequence of events. That does not mean the reader has unrestricted freedom. The available possibilities depend on what the author and programmer have implemented. A player cannot normally ask a fictional character any imaginable question and expect a meaningful response unless the system provides some mechanism for handling that request. The apparent freedom of an interactive world therefore depends upon its design. ### The difference between rules and meaning This brings us to the most important distinction in the chapter. Programs establish executable relationships. Stories establish meaningful relationships. The two can overlap, but they are not the same. Suppose our program reports: ```text True 3 ``` Technically, this tells us that `prisoner_rescued` is true and the fictional time is three. A reader might understand that Mara succeeded. But the program does not tell us whether she was frightened, whether the prisoner deserved rescue, whether the rescue came at a terrible cost or whether the experience changed her. Those questions belong to the narrative interpretation of the event. We could add more variables. We could model fear, loyalty, trust and regret. We could define increasingly complex rules. But the relationship between formal representation and human experience would remain a philosophical and artistic problem. A model can represent selected aspects of experience. It does not automatically reproduce everything that experience means. ### Stories are not just executions A story can contain ambiguity that is essential rather than accidental. It can deliberately leave a character's motivation unresolved. It can use metaphor to suggest several incompatible interpretations. It can evoke emotions that are not explicitly named. A program, meanwhile, can contain ambiguity in its intended purpose, but the operations it performs must still follow its actual implementation. This is why we should avoid claiming that every story is secretly an algorithm. The analogy illuminates structure. It does not exhaust literary meaning. A novel is not simply a sequence of state transitions. A poem is not merely a collection of grammatical rules. And a character is not reducible, for every literary purpose, to a dictionary of properties. But computational models can help us understand some aspects of narrative organisation. They also make possible new literary forms in which text and executable structure work together. ## 12. The Story That Exists Before It Is Told Let us return to Mara. We began with a simple scene. A detective enters a corridor. A door is locked. A prisoner calls for help. We then transformed part of that scene into a computer program. We defined the state of the world. We specified possible actions. We established rules governing their consequences. And we traced one successful sequence of events. Yet the program contains something the original prose does not. It contains a description of possible behaviour beyond the one sequence we observed. We could execute the actions in another order. We could change the initial conditions. We could introduce another character. We could add a rule allowing the key to break. We could make the approaching danger respond to Mara's decisions. Eventually, the program might become a small interactive world. A reader could enter it, make choices and experience the consequences. At that point, the author would no longer control every event directly. The author would control a system capable of producing events. This is a profound change in the relationship between writing and reading. In traditional fiction, the author usually determines which words appear. In computational fiction, the author may determine the rules by which words are selected, assembled or displayed. The literary work becomes partly a process. But the computer has not replaced the author. It has changed the author's task. The writer must think not only about individual sentences but also about possible states, transitions, constraints and interactions. The programmer must think not only about correct execution but also about dramatic significance, character consistency and the reader's experience. The most successful computational literature requires both disciplines. ### From describing to doing In Chapter Five, we studied codes and ciphers. We learned that a message can be represented, concealed, transmitted and reconstructed. Now we have encountered a different kind of text. A computer program is not merely information intended to be read. Under the appropriate conditions, it can be executed. Its instructions can modify information, produce output and influence connected systems. This gives programming languages a distinctive relationship with action. The sentence Mara opens the door describes an event. The instruction that changes `door_locked` from `True` to `False` modifies a computational representation of the world. The difference is fundamental. One statement participates in an imagined narrative. The other performs an operation within a defined execution environment. When the two are combined, a new form of literature becomes possible. The author writes rules. The machine executes them. The reader encounters the consequences. And the resulting story may be one that no human author ever wrote out in precisely that form. The programmer as author does not merely tell a story. The programmer can construct a world in which stories are allowed to happen. ## Questions to Take Away 1. How does the order of instructions in a computer program differ from the order in which events are presented in a novel? 2. Can a story contain a meaningful choice if the outcome is predetermined? How might interactive fiction approach this problem differently? 3. Why must a program explicitly maintain relevant information about its state, while a novelist can often rely on the reader to remember or infer that information? 4. Is a plot hole equivalent to a software bug? Under what circumstances might the comparison be useful or misleading? 5. Why can a small collection of rules generate a large number of possible event sequences? 6. Does a character controlled by a sophisticated simulation possess more literary depth than a character whose actions are described in a fixed novel? 7. What is the difference between a program executing successfully and a story being artistically successful? 8. If an interactive narrative produces an unexpected ending through its rules, who should be regarded as the author of that ending? ## A Small Experiment: Change the Ending Return to the corridor simulation from Section 6. The original program performs three actions in this order: ```python take_key(world) unlock_door(world) rescue_prisoner(world) ``` The result is a successful rescue. Now investigate what happens when we change the order. ### Step 1: Predict the result Suppose Mara attempts to unlock the door before collecting the key. The new sequence becomes: ```python unlock_door(world) take_key(world) rescue_prisoner(world) ``` Before examining the answer, predict the final state. Will Mara rescue the prisoner? Will the door open? How much time will have elapsed? Assume the program starts with a fresh copy of the original state. ### Step 2: Trace the operations The first action is `unlock_door()`. Mara does not possess the key, so the unlocking condition fails. The door remains locked. However, time advances by one turn. The second action is `take_key()`. Mara now possesses the key, and time advances again. The third action is `rescue_prisoner()`. The door is still locked, so the rescue condition fails. Time advances to three. The complete trace is: | Stage | Has key | Door locked | Prisoner rescued | Time | | --- | --- | --- | --- | --- | | Initial state | False | True | False | 0 | | After `unlock_door()` | False | True | False | 1 | | After `take_key()` | True | True | False | 2 | | After `rescue_prisoner()` | True | True | False | 3 | The final output is: ```text False 3 ``` ### Step 3: Interpret the result The prisoner was not rescued. Not because Mara lacked the necessary key, but because she performed the actions in the wrong order. This is an example of a precondition. Unlocking the door requires possession of the key. The action has no unlocking effect when its precondition is not satisfied. The fictional world therefore contains a causal dependency. The key must be collected before the door can be unlocked. The door must be unlocked before the prisoner can be rescued. ### Step 4: Create a new ending Now change the program so that Mara has four turns instead of three. You would need to modify the relevant time condition and decide which actions become possible. Could Mara recover from attempting the wrong action first? Would the story become less tense if she had more time? Would it become more interesting if she discovered an alternative route? ### Step 5: Think like an author Write a short prose version of both outcomes. In the first, Mara rescues the prisoner. In the second, she fails. Try to make the difference emotionally meaningful. Perhaps the failed attempt causes her to realise that she has wasted precious time. Perhaps the successful rescue reveals that the prisoner has been keeping a dangerous secret. The program determines whether the rescue condition succeeds. Your writing determines why the outcome matters. What the experiment demonstrates: Executable rules can establish consistent causal relationships within a fictional simulation. Literary storytelling adds motivation, interpretation and emotional significance to the events those rules produce. ## Further Reading ### Literature and Narrative Structure E. M. Forster — Aspects of the Novel (1927) Forster's original lectures distinguish the sequence of events from the causal organisation of plot. They provide a useful literary counterpart to the distinction between instruction order and computational state transitions. [Read Aspects of the Novel](https://www.fadedpage.com/showbook.php?pid=20231232) [The Open University — Story and Plot](https://www.open.edu/openlearn/mod/oucontent/view.php?id=101090§ion=_unit4.2) ### Foundations of Computing Alan Turing — On Computable Numbers, with an Application to the Entscheidungsproblem (1936) Turing's original paper develops an abstract model of computation through discrete states, symbols and formally defined operations. It remains a foundation for understanding what it means for a process to be computable. [Original paper — London Mathematical Society / Oxford Academic](https://doi.org/10.1112/plms/s2-42.1.230) [Full text transcription, reproduced with permission](https://www.verostko.com/turing/1936-paper.html) Donald E. Knuth — Literate Programming (1984) Knuth's original paper argues for constructing programs in a form designed to communicate clearly with human readers, integrating explanation and implementation. [Original paper — The Computer Journal](https://doi.org/10.1093/comjnl/27.2.97) ### Official Programming Documentation Python Software Foundation — The Python Tutorial The official documentation explains conditional execution, loops, functions, data structures and program organisation. [Python Tutorial — Control Flow Tools](https://docs.python.org/3/tutorial/controlflow.html) [Python Tutorial — Data Structures](https://docs.python.org/3/tutorial/datastructures.html) These references describe programming-language behaviour, not theories of literary meaning. The comparisons developed in this chapter are interpretive analogies rather than claims that software execution and narrative experience are identical. ### Early Computational Writing Christopher Strachey — archival further reading [Christopher Strachey scientific archive catalogue](https://centreforscientificarchives.co.uk/wp-content/uploads/2024/01/STRACHEY_CHRISTOPHER_v1.pdf) Editorial note: the catalogue was too large for the source-review tool to open. The source chapter’s precise 1952 dating and description of its contents have therefore been left out pending verification. Computer-generated love letters will receive fuller treatment in the later chapters on generative writing. ## Up Next — Words That Do Things Software, Language and Executable Reality We have learned that programs can describe fictional worlds through objects, state, conditions and rules. But computer code has a property that ordinary prose does not necessarily possess. Under suitable conditions, it can make things happen. A program can open a file, transmit a message, control a machine or change the information stored in a database. Its words are instructions interpreted by a computational system. This creates an unusual relationship between language and action. In ordinary conversation, people also use words to perform actions. A promise creates an obligation. A judge may pronounce a sentence. An official may declare a meeting open. A password can grant access to a protected system. Philosophers of language have investigated such expressions through the concept of speech acts: utterances that do more than merely describe the world. Computer programs offer a striking technical comparison. They are texts whose formal interpretation can produce real operational consequences. In Chapter Seven, we will explore speech-act theory, executable code, programming languages, software commands and the boundary between representation and action. We will also revisit literary worlds in which language appears to exert physical power, including the technological and linguistic speculation of Neal Stephenson's Snow Crash. The central question is no longer simply whether programs resemble stories. It is something stranger. What happens when words cease to describe events and become instructions that cause events to occur?