Introduction
The Infinite Woman is an interactive poetry platform that computationally performs contemporary poetic techniques of remix and erasure. As a feminist critique and artistic intervention, it remixes excerpts from Edison Marshall’s novel The Infinite Woman (1950) and Simone de Beauvoir’s book The Second Sex (1949). An n-gram algorithm procedurally generates infinitely scrolling sentences that attempt to describe and critique an eternal feminine essence. Users can select sentences from the infinitely scrolling text to send to a blank workspace, where they can erase words and rearrange sentences to create their own poems. Meanwhile, fog slowly erases the screen. The web application is hosted at theinfinitewoman.com, and should be compatible with all devices and all internet browsers (except Safari). It was selected by the Electronic Literature Organization for inclusion in the 2020 virtual exhibition (un)continuity. You can view a demo video here.
With my creative direction, the cross-platform web application was designed and implemented in 2019 by a team of Georgia Tech computer science and computational media students: Alayna Panlilio, Ryan Power, Josh Terry, Alex Yang, and Jeffrey Zhang. The development process took place in a unique context: Junior Design, a two-semester CS/LMC capstone course for computer science and computational media majors to build custom software for a client. Most Junior Design projects are purely practical—a course management system, a data visualization tool, a nutrition tracker—so proposing an experimental creative writing or visual art project was unusual. Every step of the way, we aligned each technical and aesthetic aspect of the platform with the overarching concept, synthesizing the humanist and computational spheres. For a detailed look at the students’ implementation process, view their coding sprint demo videos here, here, and here.
In September 2019, as the team was transitioning from the design phase to the implementation phase, I interviewed them about their thoughts on the computational dimensions of poetry, authorship, gender, and language. This fun, wide-ranging conversation with a brilliant group of students addresses everything from chance operations to biased algorithms to poetic structure to hacktivism to UX to aesthetics. You can find the first part of the transcript here. The team and I discuss creative coding: computational approaches to experimental poetic techniques, the syntax of coding and poetry, literalism vs. metaphor, and the tension between functionality and creative expression—reading the lines vs. reading between the lines.
The second part of the transcript, published here (edited for length and clarity), focuses on the team’s engagement with feminist computational poetics and experimental user interface design. The team and I address topics such as collaborative authorship, gendered algorithms, and the role of scripts, random probabilities, and errors in procedurally generated writing. The third installment will illuminate the project’s transdisciplinary collaborative development process.
Collaborative Authorship and Chance Operations
How do computational techniques affect literary authorship and creativity? Who has the most agency and intentionality: the programmers who write the code, the program that runs the code, or the users who interact with and modify the output? Or me, or Marshall and Beauvoir? If this thing is a poem, who’s the author?
JEFFREY: So I think that all the components together are like one big author because no matter what the program spits out it’s up to the reader to interpret it. I remember seeing an article about a comic a while back that was about a cow, and there were some strangely shaped tools on the ground next to it. And in the article, it said that the author drew the comic with the intention of showing that cows are bad at making tools. But the reader response had all these questions about, “Oh, what do these tools do?” “What are the cows planning? Are they trying to become human?” Themes and messages that the author hadn’t intended. So I’d say that all the components play a part in the message that comes out because no matter what the program or author thinks, it kind of comes down to the reader to interpret it.
ALAYNA: And even though we don’t think of the code as sentient or anything like that, we don’t really know what it’s going to spit out until we see it—even though we know what we’re feeding into it—because of the random probabilities and things like that. So even just the code itself kind of has some authorship to it.
And are the random probabilities all things you’ve built into it or could there be things you didn’t anticipate?
JOSH: The random probabilities are things that we do put into it and have some knowledge of, but some computation may slip through the cracks that has some word occur very frequently. So we might have some string of text that’s just the same word over and over and over and over again because the algorithm might break. But we can go in and edit that manually. I’ve worked in games for a little bit. And I think one thing that this reminds me of is how, in some games, you’ll have enemies that have AI to them, right, and they’ll be moving around in an area. And so, of course, the programmers wrote that AI, so programmers created those entities, but someone playing the game might say, “Oh, my God, this game is so dumb.” They’re not saying these programmers are so dumb, they’re saying this game is. And so I think it really depends on your perspective.
What is the role of chance, random probabilities, and open-endedness in producing the poem?
RYAN: I guess there is a very simple answer to this: everything. It’s a random algorithm, so it’s going to spit random results. If you flipped a coin 100 times you can get 100 heads. It’s possible. You don’t know what you’re going to get. That’s the beauty of it.
ALAYNA: This is something that I always think of: just because something is improbable doesn’t mean it’s not going to happen. Just because there’s a probability, like about dominant and recessive genes or blue eyes and stuff like that, just because you only have the recessive gene and you’re supposed to only have 25% of your kids having blue eyes, it’s possible for them to have all blue eyes. You don’t know what’s going to happen. Just because something’s improbable or seemingly impossible doesn’t mean it’s actually impossible.
JOSH: And any words that we don’t pass into this program will not appear on the page. So only words that are passed into it from the original bodies of text will be displayed on the page and the generated body of text.
As an open system, does the project generate truly infinite permutations? Or are the permutations only infinite within the constraints of a closed system (language based upon two books)?
JOSH: If we limit the amount of time that viewers can look at the infinitely scrolling text, then, since there’s a finite amount of text going in and there is a static list of probabilities for words, there will be a finite number of things that the viewer might see. But that number is so big that it’s pretty much infinite.
RYAN: I feel like it may be a high possibility that our algorithm gets stuck in a loop somewhere. If the chance of word #2 is super high to come after word #1, and #3 super high to come after #2, and word #1 to come after #3, it might do the same three words over and over again, regardless of how big our vocabulary is. So we might need to make edge cases, saying, “Hey, if this happens, don’t get stuck in a loop.”
And in that case, would refreshing the page restart it and get it out of the loop?
RYAN: Probably not. It depends on how it got to the problematic word in the first place. It may take a few hours to get there or it may start with it. But as soon as it would hit that problematic word, it may get stuck in the loop. It’s something to look out for.
JOSH: One thing we could do to handle that would be every three or four lines of text, if we don’t reach a natural end to a sentence, then we can just put a period into the next line and start a new sentence. So even if we do encounter something like that, we can create new sentences from there.
How and where is the “voice” of the “infinite woman” generated?
ALEX: Well, the way I visualize it, I feel like the user is actually kind of generating it in a sense, the way that they drag and drop to the canvas. And then, they reorder how they want the sentences to be arranged. And I feel like that in itself is creating the voice of the infinite woman. Also, it goes back to the two authors. I feel like some of the voice comes from their sentences. But mainly I feel like the user generates the voice when they generate their poem.
Gendered Algorithms
How can code perform gendered language?
JOSH: Recently, I think it was Amazon that had a big scandal where they had a bunch of predominantly white male programmers write an algorithm to determine what kinds of employees would be best for Amazon, and so that algorithm, programmed by a certain demographic of people, had a disposition that said, “Oh, hey. This demographic of person is clearly the best candidate for the job.” And they had a lot of issues regarding that AI that told them who should go to this job. So how can code perform gendered language? Machine learning, depending on who writes it, might reflect the…
ALAYNA: Biases?
JOSH: …biases of those people. Yeah. Even subconsciously. Honestly, those people probably were not trying to only hire white guys, but subconscious bias, that’s what happened. That was a big issue. I think it’s since been resolved and addressed, but worth keeping in mind.
Absolutely. How does the system select and remix gendered pronouns?
JOSH: I don’t know if our platform that we’re building will necessarily select and remix from the existing bodies of text. But because of how language works, the way that the n-gram determines what word comes after the next, oftentimes, pronouns have a lot of commonalities in what words follow them. And so if it’s “I” or “she” or “her” or “me,” then they’ll likely have similar words coming after those different pronouns. They’re also likely preceded by similar words. So the text will retain a lot of its integrity as far as readability goes, as far as syntax goes, because of how structured English is produced.
RYAN: Just to re-emphasize, the computer isn’t biased; the people who write the programs are. Whatever you tell the computer to do, it’s going to do.
Can the presence of women’s identities be detected in a disembodied digital space? How does gender become abstracted into form and process, within the code and the program?
RYAN: It can be detected if you pass the right stuff into the algorithm just because it’s like— we’ve said it a million times already, but whatever you put into it, it’s only going to use those words—right? —or a combination of those words. So if you put in text that is highly inflected with women’s identities, then you’re probably going to get something out of that. So it’s just that recurring theme of what you put in is what you get.
JOSH: The way that this algorithm works—we don’t want to caricature “feminine” words or whatever, and have that be the voice carried across from it. It’s just the text from these two authors that’s being remixed. And so if there is a lot of feminine-sounding language in what they say and if that remixed also happens to sound more feminine, then that’s how that’ll pan out.
So by continually remixing it, the patterns are revealed. Can coding be a feminist intervention?
JOSH: I think so. Yeah. There’s an organization on campus called Girls Who Code. I haven’t had anything to do with it, but optimistically, that organization could use what it has going to be a feminist intervention.
RYAN: I think the ratio of boys to girls who are actually in the field of computer science answers this question. I think it’s getting better as the years progress. But I still think coding could be considered a feminist intervention just because girls are less prevalent in the workforce in computer science. It’s like, “Hey, look at me. I’m just as good as you.”
Scripts, Executions, Errors
What is the relationship between the back-end code and the front-end interface?
RYAN: So typically, when creating an application you think of the front end as just what you see on the screen, and the back end as a database you’re pulling data from or maybe an algorithm that you’re using for the front end.
ALEX: I think specifically for our application, the back-end code would be the n-gram algorithm, which is remixing the two texts, and then that’s getting sent to the front end, which shows on the scroller.
So it’s two systems working at the same time and they communicate?
RYAN: Yeah. They’re closely tied together, though. Our application, Angular, it’s really nice because there’s three types of files. There’s CSS files, which do the styling and the look. HTML, which is basic web stuff, I’m sure you’re familiar with that. And TypeScript, which is allowing us to use methods that act like a back end, but it’s still closely intertwined with the other two file types. All three of them work nicely together. You can easily create a variable in TypeScript and send it to the HTML and vice versa. If data is changing, if you have an array with strings that are constantly changing, that will replicate what’s happening on the HTML side. So it’s really nice.
JOSH: The front end can influence the back end, and the back end can influence the front end.
How do you conceptualize the relationship between a script and its execution? If a script is a command to be executed, what is the role of errors? Can a computer “disobey” a command? Can a programmer intentionally program the possibility for errors into the script? Do bugs, unintended outputs, or disruptions to the system expose a weakness in the system, or does the system incorporate the errors as part of a more expansive, heterogenous set of possible outcomes? Do bugs kill the system or does the system just become stronger by eating the bugs? [laughter]
RYAN: They do not eat the bugs. [laughter]
ALAYNA: The role of errors and scripts and commands—if you just have a command line only, and you can only talk to this very low-level thing, if you have errors like that, could it possibly mess up your entire system? Yes. Nowadays, usually, errors and things come up in such a way that users can deal with them and look at them and say, “How do I fix them?” and things like that. Also, there are errors that shut down your entire computer. It varies on the type of error, but the role of the error-handling is to try and fix the error, if that makes sense.
Could you say more about error handling?
ALAYNA: So there are things called errors and exceptions, at least when you’re talking about Java. Exceptions are things that are going against what we usually want. To make this a little bit more colloquial, I guess we could just use errors and exceptions synonymously in this case. Sometimes you want to write a division program, right? And so you want to divide a number by another number. But if you try and divide by zero, you can’t do that. And so part of the error handling process is making sure that the divisor, the part that goes on the bottom of the fraction, isn’t going to be zero. So in order to try to fix that error you would check for that before writing your program. Building from that concept, you go through and say, “Okay, hey, where are places that this code would break?” Or if your code does break for whatever reason, it’s like, “Okay, where is this break and how can I fix that?” That’s error handling.
Anticipating errors that could happen and building in fail-safes?
ALAYNA: Both anticipating and also sometimes they just kind of show up in your face when you don’t expect them to and then you have to go back and handle them. But also, “Can a computer disobey a command?” No. [laughter] The computer always does what you tell it to do, even though what you think you told it to do may be something different.
So it reveals an error you made?
ALAYNA: Yeah, it’s usually an error that we make. Sometimes it’s just there’s something wrong with the system but yeah, it doesn’t—
No dystopian evil computers gone awry. [laughter]
JOSH: No. Not yet. There was that one thing. I think it was [Marita] Sturken and [Lisa] Cartwright. They wrote a book called Practices of Looking, and there’s some line in there that says, “Viewers make meaning.” I think that’s really cool to keep in mind. And similarly computers make meaning out of what you write to them. So you can miswrite your code, and it can do something that you didn’t think you told it to, but you did.
ALAYNA: One of the things I’m really interested in is security, like network security, cybersecurity. Even though I don’t have a whole lot of experience in that field, just the idea of it, it’s like one of those “sexy” things you can do in computer science. So, “Can a programmer intentionally program the possibility of errors into a script?” That’s sometimes what hackers will do. They implant bugs into your system, or you’ve heard of Trojan horse programs and things like that. So people do intentionally write errors in code to mess things up and to make a hole into the system, so they can break in and things like that. And then [addressing the question about] bugs or unintended outputs and whether disruptions expose weakness in the system or the system incorporates errors—the system itself can’t really incorporate the errors in any way, I don’t think. You just kind of do the error handling thing that we’re talking about here because the code itself isn’t sentient, but it may have some AI and things like that. It can try and handle the bugs itself, but it can’t really eat them. Sometimes what programmers will do is, for some specific bugs, they target a specific area. So they find a vulnerable part of a system, and they look at it, and they try and figure out how to take advantage of that. Whenever there are a bunch of bug leaks or code leaks, they may have to change the code a little bit or change the encryption or something like that in order to keep their data safe.
I love the idea of bringing hacking into it. I can’t believe I didn’t think of using that word because that could be a feminist intervention. Do you guys know about the performance group from the 90s who hacked into Barbies and G.I. Joe dolls?
RYAN: No.
There were these computerized dolls that would talk to you.
ALAYNA: Oh, okay. I’ve heard of those dolls, but I didn’t hear about the incident.
So the Barbie would say, “Math is hard,” and the G.I. Joe would say something like, “Kill, kill, kill.” And they [®™ark’s Barbie Liberation Organization] swapped it. So the Barbie said, “Kill, kill, kill,” and the G.I. Joe said, “Math is hard.” And that’s with a physical object, but it seems like hacking may be this subversion that I’m wanting. Although, I don’t want anyone to hack into our system, obviously. [laughter]
To be continued… stay tuned for the second and third parts of the interview!