Introduction

I am Teddy Roland, a PhD candidate in English at the University of California, Santa Barbara, where I study contemporary American Literature and New Media.

My research is characterized as “distant reading,” which uses computers and statistics for literary interpretation. Although the approach may appear strange at first, the questions I hope to answer are familiar ones in literary history: How do the conditions of reading and writing literature change over the past century? How does the arrival of now-ubiquitous computer technology shape the contemporary literature?

My teaching similarly prepares students for the new literacies that are asked of them by computers and AI.

For more information see the About page, as well as summaries of my Research and Teaching. Below you will find my occasional blog on the Digital Humanities.

No More Tools

The first casualties of AI were the coders. Software engineering made for easy benchmarks, since you can always tell whether a program runs or not, and there were untold programs posted to Github, just waiting to be harvested for model training. Entry-level engineers were among the first to be cut, as AI swept through the economy. The Digital Humanities has had a vexed relationship to coding, with the admonition “learn to code” always met by “code needs critique!” The critics rightly recognized that applying digital “tools” might risk displacing higher-order thought about the problems right in front of us. But AI, too, has arrived for the DH coders. Understanding how it will transform the field requires us to see more clearly how critical thinking was always part of code work.

Over the weekend, I subscribed to Claude Code. This is the AI tool that allows Anthropic’s name brand model to write code and run it in its own sandbox, with primary use cases in software development. The models have trained on a staggering amount of human-written code, covering a variety of programming languages and complex applications requiring the coordination of untold numbers of sub-programs running in parallel. Claude Code — and similar products offered by competitors — has been around for about a year, but word on the street is that an update to the underlying AI model (Opus 4.5) last November resulted in an appreciable step up in performance.

To be honest, I have held off from AI-assisted coding up to this point. Call it a distrust of code that I don’t already know how it runs. Over the course of my DH career, I have developed my own “house style,” with programming functions and workflows that are battle tested. I would stand behind them during peer review. But, a couple weeks back, Ryan Cordell shared a series of casual projects on social media for tagging newspaper articles, pulling articles published “on this day in history,” and a letter counter app for setting letterpress type. These are light-weight apps that would be nice to have, with world enough and time, but who ever does? It was Ryan’s note on one project “After < an hour iterating with CC, here’s a barebones version” that got me curious.

In a couple afternoons, I whipped up a pair of apps that implement classic DH tools. The first was a DH Toolkit web app that implements simple mapping, network viz, and topic modeling functions. I chose these three applications, since I devoted a week to each of them in an undergraduate Digital Humanities class I am teaching this semester. Students worked with a few classic applications — Google Maps, Gephi, and Mallet — while we talked about the interpretive problems they are useful to address and some of the gritty problems that come up when using the apps. Having all three applications in one place would certainly streamline the teaching, and I may do just that next semester.

The bonkers thing about the first experience is that I do not know how to code a web app. As of this writing, I do not know the Flask framework. I have only vague notions of how it interfaces between Python code on the backend and an HTML frontend. I can produce clunky 90s-style HTML at best, and I struggle with CSS. In the first iteration of the app, pages were static, but I prompted Claude to rewrite the code to permit interactive elements like zooming on maps and networks, which added Javascript elements as well. I have no background with Javascript at all. Despite all of this, Claude generated the code to my specifications and walked me through the process of installing it to a university server.

The second app turned the clock back on humanities computing. GIS, networks, and topic modeling were essential DH tools circa 2012. But casting an eye on previous decades, it was TEI that set the terms for a great deal of theory and practice. Witness, for example, the vast, painstaking efforts of Early English Books Online to manually key rare books of scholarly value (at least twice apiece, for error detection) and to provide them as structured data. The Text Creation Partnership explains that they were motivated to do so because, at the time, OCR generated such poor results. But the state of the art recently leaped forward with the new generation of vision models. I had to give it a try: “Claude, build me an automated OCR-to-TEI markup pipeline.”

The striking feature of the second app was noticing how much time I spent on the prompts. I’ll reiterate that Claude replied in a few minutes with code that would take me a month to produce on my own. But I easily spent at least 30 minutes at a stretch composing prompts to Claude that ran for several hundred words. It takes a great deal of effort to collect reference documents (like example scans from EEBO paired with their full markup files), to enumerate the many errors that arise during debugging, and to define new features that would make the program more useful. I got like 80% of the way to respectable TEI output from the pipeline before I hit my weekly limit for Claude usage.

For the curious or for those who want to kick the tires, I have posted the source code for the DH Toolkit and TEI Pipeline apps. In addition, I have also posted the transcripts of my conversations with Claude that produced each one (DH Toolkit, TEI Pipeline). I have not spent much time with the code nor the transcripts since generating them, but I am confident that both will reveal strange and embarrassing features. Bugs or Claude-specific artifacts may populate the code. My goals clearly evolve over the course of the conversations. Some of the evolution I can easily report (e.g. who I think each program’s user will be), but I would bet that there are other more subtle changes, as well, as I adapt to Claude’s level of proficiency and tics.

The first punchline here is that the old tools of Digital Humanities are now fully encompassed by AI. At a practical level, any remaining workshops on topic modeling and GIS will need to be rewritten for fundamentally different workflows. We are no longer constrained by the old problem of “other people’s software.” If there is a missing feature or an infelicitous data structure in your field’s popular software package, then simply rewrite it! If there is an onerous reformatting process for your data to play nicely with a program, generate a program that does. A silly amount of my instruction time — not to mention research time — has been devoted to massaging data or program outputs, in order to make them useable in a project. That barrier has fallen away.

At a theoretical level, we need to take a hard look at the differences between our various tools. When we start rewriting our GIS programs at will, what stops us from turning them into network graphs or spatial embeddings? The differences between latitude/longitude, edges between nodes, or vectors through geometric abstractions suddenly seem much smaller when our programs can leap between them seamlessly. The differences among various DH techniques have been flattened, or — better — reconstituted as specific manifestations of the general category of AI. Probably, we will need some media theory to account for the different forms of knowledge that each technique affords any more.

The second punchline is that tools are now telos. In order to develop any particular tool through AI, the process consists of articulating goals. As with other AI models, Claude is both eager to complete the tasks presented to it and extremely literal in its interpretation of the instructions. As a result, I put increasing effort into the specification of each tool’s users, outputs, and ways to interact with the data. But I was not telling Claude how to do go about those things. Instead, I was presenting them as desiderata. I was setting goals for Claude to pursue.

To be clear, program specification has always been an essential aspect of code work. Best practices in software engineering dictate that specification precede any actual code writing, and I expect that any self-respecting Digital Humanist would say the same. Indeed, the DHer would probably point to the galaxy of research questions they hope to address, or to the political interventions they hope to achieve, or to a “cool” interface for representing a dataset. Claude’s goal is simply to generate code, and we set its parameters downstream of our goals for the code.

There is no shortage of goals we can set for Claude Code or similar models. What we need now are criteria to select from them, and that means cultivating something like taste with respect to the goals we set for DH projects. The hardest aspect of a DH workshop or course has never been the code work but developing the participants’ intuition for the kinds of research questions that are amenable to computation. Recognizing the computable in humanistic thought and vice versa is a skill, yes, but it also requires a degree of sensitivity and imagination. With AI models like Claude Code, the bounds on our imagination have grown just a bit wider.

Aspirational Post for Public Writing

The following is a summary of my dissertation project, written for a general audience. Consider this me dipping my toe into public writing. If you want to read or hear more, please be in touch!

The new wave of AI — powered by Large Language Models — has a love affair with fiction.

The models need vast training datasets of text, since they learn about language as a matter of sheer statistical regularity. Companies like OpenAI and Meta are secretive about their datasets but, from what researchers have gathered, virtually any model you’ve heard of was trained partly on novels.

What are they doing there?

Computer scientists sometimes point to the varied nature of literary writing and refer to their encompassing generality of language. Other times, they highlight features of novels that are uniquely fictional, like an omniscient narrator.

If there is not agreement about the reason for training AI models on fiction, then it is certain that its effects have already been felt. Large Language Models have seen industrial application since at least 2019, when a model called BERT was implemented under the hood of the Google search engine.

What difference does fiction make in a Large Language Model? And what difference has it already made for users?

I address these questions using a technique that I call “critical modeling.” I study one particular dataset by identifying key historical moments in its circulation and developing computational models that reflect researchers’ and engineers’ goals at the time.

Specifically, I study the BookCorpus, a collection of ten thousand commercial novels, compiled in 2014 by a group of computer scientists. The dataset circulated widely among researchers and eventually became training data for the first generation GPT model and for BERT.

I find that models trained on BookCorpus learn how to be social. Like characters in a novel, they learn the language of motive, conflict, and pragmatism. And the effect is sustained in user-facing applications as well. We meet these characters each time we converse with ChatGPT or submit a query to Google.

By taking a “critical modeling” approach, I show that different elements of the data become salient in each application. For app users — as for novel readers — fiction gives us the chance to think about different ways we connect to one other in the real world.

There is something to love, after all, about fiction in the age of Large Language Models.

Chicago Corpus Word Embeddings

A quick post to announce the public distribution of word embeddings trained from the Chicago Text Lab’s corpus of US novels. They will be hosted by this blog and can be downloaded from this link (download) or through the static Open Code & Data page.

From the Chicago Text Lab’s description of the corpus, the corpus contains

American fiction spanning the period 1880-2000. The corpus contains nearly 9,000 novels which were selected based on the number of library holdings as recorded in WorldCat. They represent a diverse array of authors and genres, including both highly canonical and mass-market works. There are about 7,000 authors represented in the corpus, with peak holdings around 1900 and the 1980s.

Continue reading

Distant Reading: An Exam List

As a resource to future graduate students, I am sharing the reading list I compiled for my qualifying exam on Distant Reading. Below the list, you will find a user manual of sorts that explains the rationale for each of the selections.

My goal for posting is by no means to assert an authoritative list, but to offer a provisional set of principles and touchpoints for ongoing conversations in the field. I hope that many more such lists will eventually be posted, as the field matures and as new students and perspectives contribute to the project of Distant Reading.

Good luck on your exam!

Continue reading

A Naive Empirical Post about DTM Weighting

In light of word embeddings’ recent popularity, I’ve been playing around with a version called Latent Semantic Analysis (LSA). Admittedly, LSA has fallen out of favor with the rise of neural embeddings like Word2Vec, but there are several virtues to LSA including decades of study by linguists and computer scientists. (For an introduction to LSA for humanists, I highly recommend Ted Underwood’s post “LSA is a marvelous tool, but…“.) In reality, though, this blog post is less about LSA and more about tinkering with it and using it for parts.

Continue reading

What We Talk About When We Talk About Digital Humanities

The first day of Alan Liu’s Introduction to the Digital Humanities seminar opens with a provocation. At one end of the projection screen is the word DIGITAL and at the other HUMAN. Within the space they circumscribe, we organize and re-organize familiar terms from media studies: media, communication, information, and technology. What happens to these terms when they are modified by DIGITAL or HUMAN? What happens when they modify one another in the presence of those master terms? There are endless iterations of these questions but one effect is clear: the spaces of overlap, contradiction, and possibility that are encoded in the term Digital Humanities.

Pushing off from that exercise, this blog post puts Liu’s question to an extant body of DH scholarship: How does the scholarly discourse of DH organize these media theoretic terms? Indeed, answering that question may shed insight on the fraught relationship between these fields. We can also ask a more fundamental question as well. To what extent does DH discourse differentiate between DIGITAL and HUMAN? Are they the primary framing terms?

Provisional answers to these latter questions could be offered through distant reading of scholarship in the digital humanities. This would give us breadth of scope across time, place, and scholarly commitments. Choosing this approach changes the question we need to ask first: What texts and methods could operationalize the very framework we had employed in the classroom?

Continue reading

Reading Distant Readings

This post offers a brief reflection on the previous three on distant reading, topic modeling, and natural language processing. These were originally posted to the Digital Humanities at Berkeley blog.

When I began writing a short series of blog posts for the Digital Humanities at Berkeley, the task had appeared straightforward: answer a few simple questions for people who were new to DH and curious. Why do distant reading? Why use popular tools like mallet or NLTKIn particular, I would emphasize how these methods had been implemented in existing research because, frankly, it is really hard to imagine what interpretive problems computers can even remotely begin to address. This was the basic format of the posts, but as I finished the last one, it became clear that the posts themselves were a study in contrasts. Teasing out those differences suggests a general model for distant reading.

Continue reading

A Humanist Apologetic of Natural Language Processing; or A New Introduction to NLTK

This post originally appeared on the Digital Humanities at Berkeley blog. It is the second in what became an informal series. Images have been included in the body of this post, which we were unable to originally. For a brief reflection on the development of that project, see the more recent post, Reading Distant Readings.

Computer reading can feel like a Faustian bargain. Sure, we can learn about linguistic patterns in literary texts, but it comes at the expense of their richness. At bottom, the computer simply doesn’t know what or how words mean. Instead, it merely recognizes strings of characters and tallies them. Statistical models then try to identify relationships among the tallies. How could this begin to capture anything like irony or affect or subjectivity that we take as our entry point to interpretive study?

I have framed computer reading in this way before – simple counting and statistics – however I should apologize for misleading anyone, since that account gives the computer far too much credit. It might imply that the computer has an easy way to recognize useful strings of characters. (Or to know which statistical models to use for pattern-finding!) Let me be clear: the computer does not even know what constitutes a word or any linguistically meaningful element without direct instruction from a human programmer.

In a sense, this exacerbates the problem the computer had initially posed. The signifier is not merely divorced from the signified but it is not even understood to signify at all. The presence of an aesthetic, interpretable object is entirely unknown to the computer.

Teasing out the depth of the computer’s naivety to language, however, highlights the opportunity for humanists to use computers in research. Simply put, the computer needs a human to tell it what language consists of – that is, which objects to count. Following the description I’ve given so far, one might be inclined to start by telling the computer how to find the boundaries between words and treat those as individual units. On the other hand, any humanist can tell you that equal attention to each word as a separable unit is not the only way to traverse the language of a text.

Generating instructions for how a computer should read requires us to make many decisions about how language should be handled. Some decisions are intuitive, others arbitrary; some have unexpected consequences. Within the messiness of computer reading, we find ourselves encoding an interpretation. What do we take to be the salient features of language in the text? For that matter, how do we generally guide our attention across language when we perform humanistic research?

The instructions we give the computer are part of a field referred to as natural language processing, or NLP. In the parlance, natural languages are ones spoken by humans, as opposed to the formal languages of computers. Most broadly, NLP might be thought of as the translation from one language type to another. In practice, it consists of a set of techniques and conventions that linguists, computer scientists, and now humanists use in the service of that translation.

For the remainder of this blog post, I will offer an introduction to the Natural Language Toolkit, which is a suite of NLP tools available for the programming language Python. Each section will focus on a particular tool or resource in NLTK and connect it to an interpretive research question. The implicit understanding is that NLP is not a set of tools that exists in isolation but necessarily perform part of the work of textual interpretation.

I am highlighting NLTK for several reasons, not the least of which is the free, online textbook describing their implementation (with exercises for practice!). That textbook doubles as a general introduction to Python and assumes no prior knowledge of programming.[1] Beyond pedagogical motivation, however, NLTK contains both tools that are implemented in a great number of digital humanistic projects and others that have not yet been fully explored for their interpretive power.

Continue reading

Topic Modeling: What Humanists Actually Do With It

pennsylvania20gazzette

This post originally appeared on the Digital Humanities at Berkeley blog. It is the second in what became an informal series. For a brief reflection on the development of that project, see the more recent post, Reading Distant Readings.

One of the hardest questions we can pose to a computer is asking what a human-language text is about. Given an article, what are its keywords or subjects? What are some other texts on the same subjects? For us as human readers, these kinds of tasks may seem inseparable from the very act of reading: we direct our attention over a sequence of words in order to connect them to one another syntactically and interpret their semantic meanings. Reading a text, for us, is a process of unfolding its subject matter.

Computer reading, by contrast, seems hopelessly naive. The computer is well able to recognize unique strings of characters like words and can perform tasks like locating or counting these strings throughout a document. For instance, by pressing Control-F in my word processor, I can tell it to search for the string of letters reading which reveals that so far I have used the word three times and highlights each instance. But that’s about it. The computer doesn’t know that the word is part of the English language, much less that I am referring to its practice as a central method in the humanities.

To their credit, however, computers make excellent statisticians and this can be leveraged toward the kind of textual synthesis that initiates higher-order inquiry. If a computer were shown many academic articles, it might discover that articles containing the word reading frequently include others like interpretationcriticismdiscourse. Without foreknowledge of these words’ meanings, it could statistically learn that there is a useful relationship between them. In turn, the computer would be able to identify articles in which this cluster of words seems to be prominent, corresponding to humanist methods.

This process is popularly referred to as topic modeling, since it attempts to capture a list of many topics (that is, statistical word clusters) that would describe a given set of texts. The most commonly used implementation of a topic modeling algorithm is MALLET, which is written an maintained by Andrew McCallum. It is distributed as well in the form of an easy-to-use R package, ‘mallet‘, by David Mimno.

Continue reading