Genre Generators

Addison Eldin
University of Pittsburgh

This activity asks students to analyze and create *genre generators*, which are text generators that use the computer to create new instances of a formal written genre. After the instructor introduces the concept through a collaborative analysis of implementations of Christopher Strachey's *Love Letter Generator*, students then work in groups to produce non-executable conceptual programs that would produce new instances of genres they have chosen. The instructor then enacts a selection of the programs in code and leads another collaborative analysis exercise in order to highlight the rhetorical and social dimensions of the decisions that students made in the process of automation via a digital computer. By emphasizing the programming process and not asking students to code, students can develop a better understanding of how computer programs mediate digital technology and human understanding of the world.

Learning Goals: 

  • Be able to distinguish the acts of programming and coding while understanding their interrelations
  • Connect extant rhetorical analysis abilities to the analysis of code and its output(s)
  • Engage in programming such that both human decision-making and technical limitations are considered

Original Assignment Context: Intermediate-level digital humanities course

Materials Needed: a higher level programming language that allows for the manipulation of text strings with lists and variables (e.g. Python, which is used in `generator-template.ipynb`), the ability to present code and text in sequence (e.g. Jupyter Notebooks, which can present Python and Markdown in sequence, as shown in `generator-template.ipynb`)

Time Frame: ~2 sessions

Introduction

*Genre generators* are text generators that use computer code to produce and manipulate text and create new instances of a formal written genre.1 This in-class activity, which walks students through the process of creating their own genre generators, is intended not to teach computer code—which requires knowledge of how to use specific programming languages—but rather *programming* as a conceptual process enacted by people to mediate between the world, their understanding, and digital technology. Where *coding* requires adherence to the rules of one or more programming languages, *programming* is the conceptual process whereby the problem is reworked and solved more generally. Think of it this way: to program is to know you might need a list of words that is pulled from at random in the generation of a new sentence, while to code is to know how to define and choose objects from a list using a specific programming language.

This activity was created for a course called "Digital Humanity," which is an undergraduate course that covers several topics around being human and the meaning of *humanity* in a time of digital ubiquity. It focuses on technological and social elements of computers in tandem to frame the various topics in the course. As described in the next section, this context directly led to the creation and shape of this activity.

While certain parts of digital technology, programming, and code will need to be established by the instructor in class before the activity, students themselves will not need to produce any code that can be run on a computer, as the emphasis is on programming. This distinction can help students understand that the computer is at once technical—that is, a material object with certain ways of functioning that create both limitations and affordances, as is the case with technology generally—and social—that is, made use of by human beings for human-defined goals based on their understanding of the world around them.

The activity, which runs for at least part of two sequential in-class meetings, leverages students' experience with and understanding of *formal written genres* to collectively analyze implementations of a specific computer program, Christopher Strachey's *Love Letter Generator*.2 Designed in the early 1950s, Strachey's generator stands out in the history of computers for its use of computational resources and programming for the purpose of text generation. Strachey worked from a handbook compiled by Alan Turing for the Manchester Mark 1, one of the earliest stored-program computers, and created a lengthy program that put the computer's resources toward something distinctly human—the writing of love letters.3

Once the relevant aspects of formal written genres are recalled and applied,4 students make use of this knowledge to understand how the implementations of the Love Letter Generator enact our understanding of the love letter as a genre through looking at the code underlying them, with an emphasis on broad concepts used in programming such as string generation and manipulation as well as the use of lists and variables. Then, in small groups, they define a different written genre (e.g. an email to their professor, an obituary, or a job ad), identify its purpose and key features, and consider which elements of the genre can be represented with digital technology via programming. Finally, the instructor enacts a selection of the student programs in code, turning the analysis toward the students' genre generators to draw out the way the students' practices were, like programming more broadly, a back and forth between the computer's technological basis and the non-technological understanding of genres that they represented with that technology.

Context

The original context for this activity was "Digital Humanity," a course that intertwines the technological and social elements of the computer to frame conversations about being human and the meaning of *humanity* in a time of digital ubiquity. It serves as a philosophy general education requirement at the University of Pittsburgh for majors in fields across the humanities, social sciences, and natural sciences, but also acts as a major requirement for students in Digital Narrative and Interactive Design, an undergraduate major which incorporates courses from the English department and the School of Computing and Information. While its audience includes and benefits students who code, there is no presumption of technological facility beyond that required by the university more broadly: the ability to use a web browser, email, learning management systems like Canvas, word processing technology, and video conferencing software like Zoom.

The course's focus on the technological and social elements of computers in tandem guided the design of the syllabus the first time I co-taught it with one of the original developers of the course,5 as well as the second time when I taught it alone. I wrote this activity for this second iteration after reviewing a shared teaching document: one week, Prof. Langmead used the Love Letter Generator as the basis of a conversation, and the program seemed perfect for helping students grasp how *programming* involves a person who makes interpretive decisions about how to represent the world.

Implementation

Despite the idiosyncratic context from which this activity arose, I think there are three broad criteria that can help someone identify if this activity is appropriate for their course.

  1. The course should, in part or in whole, speak to the social and creative dimensions of programming and coding for digital technology. That is, some part of the course should speak to how ideas such as digital representation, digital computation, and/or encoding are relevant processes in the human use of the technology.6 Relatedly, the course should spend some time prior to the activity discussing these concepts—whether in those terms or through a focus on programming and code—to prepare students for the conversation about the Strachey implementations that will prompt students' own creative work in developing a generator.7
  2. Students should, generally, have some experience with college-level writing. The instructor will guide students through the basics of rhetorical analysis by considering the rhetorical context, purpose, and norms of a written genre, namely the love letter, as a review of basic concepts often covered in first-year writing courses. Students who have taken a first-year writing course or otherwise learned about different kinds of academic writing—e.g. what differentiates an essay and a research paper—will be better situated to engage in this conversation. A class made up of students who are new to college and have no prior college writing experience might find this conversation more difficult, which could make the rest of the activity difficult.
  3. While students do not need to know how to code or what programming is in advance, the instructor must have basic facility with at least one higher level programming language that enables the manipulation of text, e.g. Python or Javascript. The basic skills required include coding strings, variables, and lists in conjunction with each other. Further, the instructor will need to be able to present the code and its outputs in sequence with text that contextualizes the code with some kind of projection technology.

If these three criteria are met, I believe that the activity could be implemented into a course regardless of its home department. While the rhetorical analysis part of the assignment might seem limiting in terms of instructor comfort with guiding the discussion, I think that the questions provided in `instructional-guide.md` and the instructor's own awareness of the contexts, purposes, and norms of written genres in their own field are sufficient for facilitating the rhetorical analysis in the activity.

Instructional Materials

All instructional materials for this activity—including an instructional guide, a student program and its implementation in code, and a template generator in Markdown and Python using Jupyter Notebooks—are available via a GitHub repository (https://github.com/addeldin/genre-generators).

There, you will find:

  • `README.md`, which guides you through the contents of the repository;
  • `generator-template.ipynb`, a template that can be updated with specifics from a student program;
  • `instructional-guide.md`, which guides you through the activity;
  • `student-program.pdf` and `student-generator.ipynb`, which are examples of a student program

Notes

  1. *Formal written genre* is meant to contrast *genre* as used in the phrase *genre literature*, e.g. horror, fantasy, or science fiction. Formal written genres describe the different formal genres of writing such as the letter, novel, government report, etc.
  2. The two implementations of the Love Letter Generator used are Matt Sephton's (https://www.gingerbeardman.com/loveletter/), which presents outputs of the generator, and Annette Vee's (https://jsfiddle.net/nettework/6f7abaaa/), which presents outputs along with the underlying Javascript code.
  3. For a brief, accessible history of the Strachey project, see Siobhan Roberts' 2017 article in *The New Yorker*. A link is provided in the References section.
  4. For examples of relevant approaches to the study of genre from a composition and rhetoric perspective that account for the rhetorical dimensions of written works in social contexts, see the cited works by Rebecca Nowacek (28), Charles Bazerman (69), and Carolyn Miller (59).
  5. Alison Langmead, a faculty member in the History of Art and Architecture Dept as well as in the School of Computing and Information at University of Pittsburgh.
  6. By *digital representation*, *digital computation*, and *encoding*, I refer to the fact that to represent a concept using a computer, that concept must be represented digitally, or via discrete numbers, generally the binary digits 0 and 1, which are then computed in various combinations to produce new results. For example, to represent the continuous color spectrum, colors are encoded via digital representation by encoding any color as a combination of 256 possible shades of red, green, and blue. While over 16 million colors is a lot, it is not a direct reflection of the full color spectrum, which due to being continuous necessarily contains an infinite number of possible colors.
  7. For resources that can develop an understanding of digital representation, digital computation, digital encoding, and/or the basic concepts of programming for the instructor as well as the students, consider Karen Hao and Jonathan Stray's relatively short breakdown of how a courtroom sentencing algorithm digitally represents ideas of justice and risk; Charles Petzold's book *Code: The Hidden Language of Computer Hardware and Software*, in particular the chapter "Bit by Bit by Bit"; or Paul Ford's in-depth but highly readable *Bloomberg* article, "What Is Code?" All of these texts were used in both terms that I taught "Digital Humanity," with "What Is Code?" being assigned and discussed in the class session prior to the start of this activity.

References

Bazerman, Charles. "Systems of Genres and the Enactment of Social Intentions." *Genre and the New Rhetoric*, edited by Aviva Freedman and Peter Medway, Taylor & Francis, 1994, pp. 67-85.

Ford, Paul. “What Is Code? If You Don't Know, You Need to Read This.” *Bloomberg*, Bloomberg L.P., 11 June 2015, https://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/.

Hao, Karen, and Jonathan Stray. “Can You Make AI Fairer than a Judge? Play Our Courtroom Algorithm Game.” *MIT Technology Review*, 10 Jan. 2022, https://www.technologyreview.com/2019/10/17/75285/ai-fairer-than-judge-criminal-risk-assessment-algorithm/.

Miller, Carolyn. "Genre as Social Action (1984), Revisited 30 Years Later (2014)." *Letras & Letras*, 2015, pp. 56-72, doi:10.14393/LL63-v31n3a2015-5.

Nowacek, Rebecca S. *Agents of Integration: Understanding Transfer as a Rhetorical Act*. Southern Illinois UP, 2011.

Petzold, Charles. *Code: The Hidden Language of Computer Hardware and Software*. Microsoft Press, 1999.

Roberts, Siobhan. "Christopher Strachey's Nineteen-Fifties Love Machine." *The New Yorker*, 14 Feb. 2017, https://www.newyorker.com/tech/annals-of-technology/christopher-stracheys-nineteen-fifties-love-machine.

The Assignment

Top-Level

This activity takes place over two sequential in-class sessions. While the activity does not need to take up two full class sessions, the break is necessary so that the programs students design in groups can be implemented in code by the instructor and then shared back to students during the next session.

The first day of the activity should take between 50 minutes and 1 hour and 25 minutes, and the second day should take between 30 and 45 minutes. I have provided estimates for how long each part of the daily activities will take, but these may need to be adjusted based on instructors' sense of which parts students will struggle with.

Please note that this guide is just that: a guide. You are welcome to change it as you see fit for your classroom, and I would in fact love to hear about anyone doing so and how they went about the activity.

This instructional guide is available here as well as in the related GitHub repository ((https://github.com/addeldin/genre-generators), which further includes samples of student work for this activity and a Jupyter Notebook template for implementing student genre generators. If you wish to edit the instructional guide, I recommend downloading and editing `instructional-guide.md`. 

Session 1

Setup (estimate: 5-10 minutes)—

To begin, tell students about the overall arc of the activity, as related in the README.

Then, introduce students to the concept of *genre* from a rhetorical perspective rather than the more colloquial use. That is, talk about written genres students are likely to encounter in class—e.g. a non-fiction personal essay, a research paper, or an argumentative essay—and distinguish this understanding of genre from the broader use that distinguishes by narrative tropes, such as science fiction, fantasy, and westerns. Whereas the former is defined by the exigence for writing based on a specific context (generally, college writing assignments) and toward a specific audience (the instructor or an imagined community relevant to the discipline, such as attendees of an academic conference), the latter tends to focus on consistent narrative tropes and structures.

Prompt students to name written genres that fit this definition. If needed, provide some examples, such as emails to a professor, obituaries, recipe blog posts, news articles, etc.

Love Letters as a Genre (estimate: 15-20 minutes)—

The setup conversations lead directly into a rhetorical analysis of the love letter genre using sample outputs from Matt Sephton's implementation of the Strachey Love Letter Generator (https://www.gingerbeardman.com/loveletter/), which is useful because it only shows generated outputs. Show students several sample letters, and ask:

  • What changes for each new letter?
  • What stays the same?
  • What do the consistent features (e.g. a personalized salutation using a pet name) tell us about the purpose of a love letter?

Then, ask questions that consider the rhetorical dimension of love letters more broadly:

  • What is a love letter?
  • Why does it exist?
  • When is this genre used?
  • What are some key features of love letters?

Love Letter Generation and Code (estimate: 20-25 minutes)—

Once the foundations of genre, love letters, and the Love Letter Generator are established, show students Annette Vee's implementation (https://jsfiddle.net/nettework/6f7abaaa/271/), which is useful because it presents the outputs along with the underlying code. For the purposes of this activity, the HTML and CSS windows can be contracted in favor of the JavaScript and output windows.

Remind students of the consistent features they identified when looking at the sample outputs of the Sephton iteration. Then, facilitate a conversation where students try to connect the word lists listed under `var` on line 4 to several outputs of the generator—e.g. how the words in `salutations1` and `salutations2` are, despite changing each time, consistently pulled from the two respective lists, which contain the opening salutation and pet name that follows it, respectively.

While the `for` loop that starts on line 45 might be harder to parse, look at the `else` statement on lines 52-54 and try to relate how the combination of "YOU ARE MY", a selection from a list called `adjectives`, and a selection from a list called `nouns` is reflected in the body of the sample letters.

Cap off this part of the activity by emphasizing the essential tools used to generate new love letters: text strings, lists of words that can be chosen from at random and inserted into a text string, and the use of variables in text strings to create differences between sample outputs.

Group Programming Exercise (estimate: 20-30 minutes)—

Break students into groups of between 4 and 6 students. If a subset of the class has experience with computer programming, distribute them evenly amongst the groups, as they might be able to guide how students enact their ideas into a conceptual program.

Ask them to respond to the following prompts in a collaborative written document and either turn in the paper or send their document to the instructor digitally at the end of class. 

  1. Identify a written genre.
  2. Why does this genre exist? When is it used?
  3. What are the key features of the genre?
  4. What key features might be easy to encode? What might be difficult?
  5. Create a mix of text templates, variables, and lists that could generate new instances of this genre based on the features you have identified. 

Emphasize that you will enact a selection of the student programs in code to present for the next class.

Between Sessions

Identify 1 or 2 student programs that seem particularly viable to represent in code. For example, broadly described generator programs that do not contain lists or templates that interact with variables will require more labor on the part of the instructor to translate that program into code. While there are many potential approaches students can take, an ideal program for this activity will provide a basic string template, a list of words that is chosen from for parts of the template, and potentially variables that are called (e.g. the current time of day using the `datetime` module in Python). 

Present text from the student document that states the chosen genre, the students who designed the generator, the description of that genre, and the key features they identified. Then, demonstrate the code that enacts the program with comments that explain what a given section is doing. The code should be presented in software that can run the code and present outputs along with the code, so that the generator can be run repeatedly to look at several different outputs.

For the materials included in this repository, I used Jupyter Notebooks to present text in Markdown in sequence with enactable code in Python. Please see `student-generator.ipynb` for an example, or `generator-template.ipynb` for a notebook that can be easily edited and added to by instructors.

Session 2

Setup (estimate: 5 minutes)—

Briefly summarize the activity of the previous session, in particular for students who may have been absent the previous meeting.

Process Reflection (estimate: 5-10 minutes)—

Ask students the following questions to encourage them to reflect on their processes:

  • How did your group take your genre and design a generator for it?
  • How did you consider the role of the computer as you designed?
  • What did you leave out of your generator that is part of the genre you described? Why?
  • Would you call what your group did *programming*?

I used the final question as an opportunity to reinforce the broader idea behind the activity: programming is a conceptual process that mediates human goals and representations of the world and the digital technology that works with these representations in code. While their decisions had to account for the technical elements of digital technology, they were still making decisions about what a genre is, who it's for, when it's used, and what elements define it. They programmed by considering how to take their goals in defining a genre to generate new examples and make them work in the logic of digital technology. While the instructor does the actual coding, which is itself mediational, the focus is on how the students mediated human understanding and digital representation.

Genre Generator Presentation (estimate: 15-20 minutes)—

Show students the formatted text and code. Read through the name of the genre students chose, the names of the students who designed the generator, their description of the genre, and the key features they identified. 

Relate a key feature to the code, which can generally be broken up for readability similar to the Vee implementation of the Love Letter Generator. For example, have all of the lists of terms in sequence, then the variables that choose from the lists, then the string template that makes use of the variables. If students identified that a salutation was important for an email to a professor, for example, then relate this key feature to the lists, variables, and place in the template that generate the salutation.

Show several sample outputs of the generator and ask students to identify which key features they can see in the outputs, and try to relate those outputs to what they can see in the code.

Rhetorical Analysis of the Genre (estimate: 10-15 minutes)—

Guide students through a rhetorical analysis of the genre as a mirror of the first session's discussion on love letters. You might ask about a number of specific features in the generator, but these general questions are useful starting points:

  • What does this generator tell us about this genre?
  • Why does this genre exist, and what does it do?
  • How does this generator reflect these aspects of the genre?
  • What aspects of the genre are important that you do not see included here? Why might they not be present in the generator?

The final question I like to ask to reiterate the sociotechnical nature of the genre generators is:

  • Do these generators objectively identify what their respective genres *are*, or their key features? 

Guiding Realizations

  1. Although the computer mechanically produces new instances of the genre based on pre-defined rules, there are still subjective decisions about what a genre is and how to represent it that are embodied in the code.
  2. There is a distinction between *programming* as a conceptual process of shaping real-world things or ideas in terms that can be understood and processed by the computer, and *coding* as enacting those ideas in machine-readable language.
  3. To define something like a genre in a way that can be interpreted by a computer does not mean that this definition is the only or most correct way to understand what that genre is. By virtue of making the genre fungible to the logic of the computer, certain understandings of the genre were prioritized and others, de-prioritized.