Introduction Excerpt for Programming Language Cultures
INTRODUCTION
Eating the World
I
“More and more major businesses and industries,” Marc Andreessen observed in “Why Software Is Eating the World,” published in the Wall Street Journal in 2011, three years into the Great Recession, “are being run on software and delivered as online services—from movies to agriculture to national defense. Many of the winners are Silicon Valley–style entrepreneurial technology companies that are invading and overturning established industry structures.” Andreessen, best known as the co-founder of Netscape Communications Corporation and the venture capital firm Andreessen Horowitz, used the phrase “software is eating the world” to describe the unexpected, yet undeniable explosion of so-called Web 2.0 or social media platforms amid the widespread economic suffering and the self-destructive austerity politics of the time, from which the tech industry appeared, this time, to have engineered a successful escape. “More than 10 years after the peak of the 1990s dot-com bubble,” as Andreessen put it, “a dozen or so new Internet companies like Facebook and Twitter are sparking controversy in Silicon Valley, due to their rapidly growing private market valuations, and even the occasional successful IPO. With scars from the heyday of Webvan and Pets.com still fresh in the investor psyche, people are asking, ‘Isn’t this just a dangerous new bubble?’” “I, along with others,” Andreessen told the Wall Street Journal’s readers, “have been arguing the other side of the case” (Andreessen 2011).1
It is accurate enough and unhyperbolic to state that since the early 2000s, a meaningful intensification—which is technical but also cultural, economic, and political in character all at the same time—has generalized an awareness of radical and profound infrastructural and organizational dependence on software. That is to say that possibly for the first time in a longer history of computing, such awareness has become very widely distributed outside the tightly coupled classes of technical experts we call software engineers and their managers. Now, that awareness is also alive among many of those who may not build software applications for a living, or directly manage those who do, but whose livelihoods in financial services, media, education, and other domains are equally inconceivable without the mediation of the software industry.
Only six years after Andreessen’s pronouncement, things looked somewhat different, as the magnitude of the side effects of a narrowly software-driven recovery first came into view. “For the last year,” Biz Carson wrote in Business Insider on November 12, 2016, “the tech industry has been fretting about a bubble. Investors on all sides argued over whether valuations were too high or whether the tech sector as a whole was still undervalued. Yet while Silicon Valley was obsessing over the startup bubble, it collectively failed to realize it was living in a completely different kind of bubble: a political bubble. As the reality struck late Tuesday night that Donald Trump would be the next US president, tech leaders found themselves reeling.” Trump’s election win, Carson concluded, deliberately echoing Andreessen’s phrase, “signaled to Silicon Valley that it’s time to look outside the bubble. Software has eaten the world, and this is what’s been vomited back up” (Carson 2016).
Whether its motive is boosterish or critical, it is still common today to hear that software runs the world, that life as we know it is impossible without software, or that software is “eating the world”—not necessarily as a good thing, but certainly as an inevitability. Such statements aren’t simple fictions. But they are often what I’d call marginally dishonorable, in two ways. Their first problem is that much of life as we know it has been running on software for nearly seven decades already. What we now call stored-program electronic computing, in which instructions for computation are represented as data in memory, dates to 1949. The UNIVAC I, the first successfully marketed commercial stored-program computer, was in wide use by 1954, installed at facilities operated by manufacturing giants including General Electric, U.S. Steel, Du Pont, and Westinghouse; insurance companies including Metropolitan Life, Franklin Life, and Pacific Mutual Life; utility companies like Consolidated Edison; US government agencies including the Census Bureau and Atomic Energy Commission; and divisions of the US armed forces including the Air Force, Army, and Navy. We tend to think of the 1960s as the decade in which the US economy was “digitized,” but as James W. Cortada reminds us in his three-volume historical study The Digital Hand, the immediate and widespread commercial success of the IBM 650, introduced in 1953, suggests that the operations of big companies in the US manufacturing, transportation, retail, financial services, telecommunications, media and entertainment, and public sector industries were in many ways already reliant on computing by the end of the 1950s.2
That is to say that the long march toward the estimated 220 billion lines of mission-critical legacy code in the Cobol programming language still running on mainframe computers today, disproportionately at banks and other financial service providers, was well under way by 1959, when Cobol was first introduced.3 There is, in other words, nothing especially new here. One does not hear similarly aggrandizing claims about nuclear energy, mass-produced plastics, color television, or other indispensable and ubiquitous technologies whose emergence also dates to the 1940s. Consider, for example, the brief introduction that Josh Tyrangiel, then editor of Bloomberg Businessweek, wrote for “What Is Code?,” the article he commissioned Paul Ford to write in 2015 that became internet-famous as a 38,000-word interactive web feature comprising an entire issue of the magazine. “Software has been around since the 1940s,” Tyrangiel wrote. “Which means that people have been faking their way through meetings about software, and the code that builds it, for generations. Now that software lives in our pockets, runs our cars and homes, and dominates our waking lives, ignorance is no longer acceptable. The world belongs to people who code. Those who don’t understand will be left behind.” While its rhetorical purpose is clear enough, none of the reasoning in this brief paragraph actually follows from the premise expressed by its first and second sentences.4
The second problem with a pronouncement like “software runs the world” is that it directly serves both the economic advantage and the generalized economic, political, and cultural authority of a very specific kind of technical expert, the computer programmer or software developer or engineer, whose economic role, along with those of other experts who directly support or exploit the programmer’s work, has now been elevated beyond reasonable measure. It’s safe to say that the violence of the companion phrase “eating the world,” its assertion of destructive privilege, is an intended violence: one part opportunism, conscious or otherwise, and one part naked aggression, reflecting the succession of the Wall Street i-banker by the Silicon Valley tech bro in public economic-historical lore. Though their work conditions aren’t perfect and they gripe like anyone else, software engineers went uniquely unscathed—indeed, made out like bandits—during the extended era of austerity and generalized economic pain and suffering that began in 2008. Many remained insensitive to the context of their good fortune, in some cases all the way up to the painful sobriety imposed by the unprecedented industry contraction that began in mid-2022. One ought not to join the chorus here, given how nakedly such talk reflects the extensive economic violence of that earlier interval, a period in which “learning to code” was imagined sometimes confusedly, but often cynically, as something like a universal pathway to reemployment.
II
While one cannot deny the importance of software, one might insist on the meaningful difference between the circular reasoning of such pronouncements—“software is important; important things deserve attention; therefore software deserves attention”—and the historical, economic, and political questions of how and why software came to be so important, along with the normative question of whether software’s importance is, on balance, something good or something bad.5 This book is a study of the powerful autologies or self-referentialities of programming language cultures, which programmatically elide such questions.
Autology is the opposite of heterology, a difference of origin or an incommensurability of parts. Computer programming is polyglot and translational, and no program, even a small one, can be written without resorting to various kinds and modes of bindings, hooks, and other established or improvised, approved or undocumented interfaces, forming a heterology both virtual and fragile. This is both true and obvious. I would suggest that these are not in fact programming’s specially interesting characteristics, and they are not the characteristics it is urgent to document and analyze, today. Software engineers are in no way reluctant to admit, even to highlight, the persistence of bugs, crashes, security lapses and breaches, and all kinds of more serious disasters attending their work, and to acknowledge that at some level, given the technical dynamics of software production, such problems can never be completely eliminated. The practical activity of nearly every software engineer is nonetheless dedicated to avoiding or eliminating such disorder, because software engineering resources, incentives, and rewards are all aligned with that autological purpose. “Autology” here marks this continuous, insistent orientation toward purified self-reference, toward eliminating the disruption and alienation of error, which we find in the absolute centrality of debugging to programming: error, errancy, are always assumed, but also always opposed. The bug is hunted to be squashed, and the hunt never stops.
In a broader sense, autology refers to programming’s special and privileged role in automation. Donald E. Knuth put it directly and unambiguously, remarking that “computer science answers the question ‘What can be automated?’” (Knuth 1996, 3). While the most proximate reference of this remark is the emergence of the discipline of computer science from automated theorem proving, an early application of computers, Knuth clearly intended it as a generalization. The so-called programming language hierarchy, in which one abstract schematic after another, from mnemonics for operation codes to high-level languages incorporating English-language (or other natural-language) words and phrases, facilitates the automation of activities formerly performed manually, should be understood as an emblem of the generally recursive automation of programming as a political-economic activity: an activity that has no purpose but to automate other labor activities, not excluding itself. Automation of the jobs worth having: that’s what a programming language culture does.6
And you can’t understand the culture without understanding its language. On this point I agree with humanities-based and sociologically oriented critics and scholars in the domains of platform studies, software studies, and code studies whose perspectives I might otherwise characterize as technically or technologically deterministic. Today our general intellectual culture is almost completely paralyzed by technical ignorance of computing. In chronicling the process of “learning to code in middle age,” Andrew Smith is correct to argue that “by accident more than design, coders now comprise a Fifth Estate and as 21st-century citizens we need to be able to interrogate them as deeply as we interrogate politicians, marketers, the players of Wall Street and the media” (Smith 2018). During the widely celebrated testimony of Facebook CEO Mark Zuckerberg to the US Senate Committee on Commerce, Science, and Transportation on April 10–11, 2018, there was much snickering among techie journalists, academics, and others who felt themselves in the know. But the truth is that while Gen Xers and millennials who grew up with BBSs, IRC, listservs, and then Web 1.0 still know quite a bit more than your average US senator about Facebook, Twitter, and the rest of Web 2.0, most are closer to the senators’ ignorance than they are to true technical knowledge, particularly of the creation and maintenance of software infrastructures. (There was visibly less snickering during the testimony of TikTok CEO Shou Zi Chew to the US House of Representatives Energy and Commerce Committee on March 23, 2023, which among other things suggests how significantly the ideological hegemony of the tech industry had faded during the intervening five years.)
In this book, I have focused on consolidating and generalizing the latter form and mode of technical knowledge, of the creation and maintenance of software infrastructures, from a humanities-based yet not humanities-enclosed perspective, as a preface to—but certainly not an overtaking or elision of—a truly effective critique to come. To date, attempts to generate a political-economic theory of digital labor have focused more on semiprecarious digital piecework and so-called “free” contingent labor than on the relatively or distinctly elite work of the programmer.7 Sociologically oriented business histories have offered valuably detailed documentation of the histories of computer programming and computerized data processing as elite professions, but less close or extended study of programming languages and their usage infrastructures in themselves.8 Political philosophy generally, even in the accelerationist mode that enjoins the left to “develop sociotechnical hegemony,”9 still remains remote from technical realities. While the same cannot be said either of philosophical approaches to software as media, or of culturally oriented research in the politics of computation, such work prioritizes theoretical interpretation and its scope tends to exceeds software as such,10 though in this area at least one sociologically oriented cultural studies scholar has documented specific cultures of software development in work that is laudable for being simultaneously technically detailed and socially focused.11 While scholarship in the literary humanities has been receptive to such research in so-called software studies, it has not displayed a proportionate interest in the specifically social and cultural dimensions of the specifically linguistic history of computing, as one would expect it to do—and this is the case especially where individual programming languages and their development and usage cultures are concerned.12 The broad exception is, of course, in the narrative historiography of computing and in science and technology studies more broadly. But even here, Mark Priestley is surely right to suggest that early, purely technical histories of programming languages have been followed by socially attentive histories of software as a general object and domain, leaving individual programming languages behind as objects of potentially equally both technically and socially focused study (Priestley 2010, 2).
Granting that no duplication of the early, narrow technical histories is necessary—they were meticulous, if unsurprisingly disproportionately anecdotal in character13—how can we describe the humanities research space separating an early historiography of programming languages that is as old as the Fortran, Lisp, Algol, and Cobol languages themselves (which originates, that is to say, in the late 1950s), and recent social histories of the software concept such as Martin Campbell-Kelly’s From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry (2004)? A clue is to be found, I suggest, in an essay by William Paulson titled “For a Cosmopolitical Philology: Lessons from Science Studies” (Paulson 2001), insofar as in that essay, published in 2001, Paulson suggested the value of bringing science and technology studies (STS) scholarship into contact with an older literary humanist tradition of philology: a tradition whose methodologies were globally comparative and multilingual, whose mode was the study of texts in multiple languages (which required intensive study of the languages themselves), and which was rooted in a specific Western intellectual-historical tradition, the tradition of secular or historical humanism. If we set aside this latter tradition (one that STS scholars would surely understand themselves as sharing with “philologists,” that is, with language and literature scholars), philology’s characteristic mode of focus, grounded as it is in the mandates of linguistic specificity, even incommensurability, cannot be described as a great strength or even necessarily a normal characteristic of scholarship in STS.
From a position close to Paulson’s own, one might invite software studies and so-called critical code studies, as well as STS itself, to establish an as-yet imagined contact with philology. How might we imagine a philological study—that is, a minimally both technically and socially oriented, but specifically linguistic historiography—of a specific computer programming language, or a specific characteristic of a type or family of programming languages, or the social and historical context of a particular programming language feature and its place in a culture of software development? For an example of how such questions might be posed within the disciplinary context of the information sciences, we can consult recent work like Amy J. Ko’s “What Is a Programming Language, Really?” “In computing,” Ko remarks, “we usually take a technical view of programming languages (PL), defining them as formal means of specifying a computer behavior. This view shapes much of the research that we do on PL, determining the questions we ask about them, the improvements we make to them, and how we teach people to use them. But to many people, PL are not purely technical things, but socio-technical things” (Ko 2016, 32). Still, essays like Ko’s are remarkably few and far between, in the domain of the technical sciences as much as in the social sciences and the humanities—and often, as in this particular case, perhaps unavoidably perfunctory. Regardless of how we choose to explain it, Ko’s conclusion that “other agendas, particular those that probe the human, social, societal, and ethical dimensions of PL, are hardly explored at all” (Ko 2016, 33) is certainly warranted.14
III
Put more generally, this book’s goal is to demonstrate one way of integrating humanistically based but not humanistically constrained study of both the histories and the technical characteristics of programming languages into the broader cultural history of technical expertise in computing established by the research of Jennifer S. Light, David Alan Grier, Janet Abbate, Nathan Ensmenger, Margot Lee Shetterly, Mar Hicks, and Charlton D. McIlwain, among other scholars.15 I know this research well and I admire it highly. It is the closest thing to an existing point of departure for my own work in this book, and so it is cited, both individually and collectively, at some key moments. Nonetheless, its contact with philology, as I have discussed it here, is glancing at best and generally negligible, employing neither the word nor the concept. This body of work is in no way diminished by that fact. As the product of scholarly training and dispositions that are historiographic, but not specifically linguistic-historiographic, its orientation to our common topic is certainly proximate, yet also orthogonal to my own.
Another point of departure might be represented by the work of Ted Nelson, Alan Kay, Seymour Papert, Michel Resnick, and other trained or untrained computer scientist-engineers whose consilient devotion to broadly pedagogical, creative, expressive, and other personal or personalist applications of computing won them many friends in the arts and humanities, as well as some imitators. I have written elsewhere16 of the fundamental literariness of Nelson’s imagination of a file system capable of accommodating and co-producing the true dynamic of knowledge as a “disappearance and up-ending of categories and subjects” (Nelson 1965, 96). Nelson’s treatment of computers as humanist “dream machines” and “literary machines” represents an aestheticizing radicalization of the philological approach that goes well beyond my own inclinations in this book. The work of Papert, Kay, and Resnick on the Logo, Squeak, Etoys, and Scratch programming languages and environments, among other projects, is widely regarded as a more successfully institutionalized bridge from computer science to the humanities—and with good reason, despite the troubled legacy of the One Laptop per Child project with which all three men were involved.17 More recently, the Racket programming language, environment, and associated pedagogical tools and materials, including the textbook How to Design Programs, have proposed reforms to postsecondary instruction in computing that carry the motives of Papert’s, Kay’s, and Resnick’s projects forward into an age of ubiquitous and generalized computing.18
Here, too, this is research that I admire, and with which I have long been familiar. If it is less proximate as a point of departure for my own work in this book, and thus goes unacknowledged beyond this introduction, that is for reasons beyond its equidistant remoteness from philology. First, with the possible exception of Nelson, who deserves a category of his own, none of these researchers goes as far as Donald E. Knuth in bringing literature, specifically, to meet programming, specifically, as I have described this part of Knuth’s work in chapter 2—without also tipping into potentially facile conflations of code with language, or knowledge of programming with literacy. The latter two category mistakes, unfortunately widespread in the contact zone between programming and other kinds of writing, are problematically aggressive on the humanities’ own side of the border, where attempts to gather technology into philosophy, and thus buttress the latter’s primacy, are a longstanding project. By contrast, Knuth’s concept of “literate programming,” as I describe it in chapter 2, borrows terms and concepts from literature as a discrete and distinct domain, without subsuming programming in literature or subsuming literature in programming. Knuth’s actual practice of literate programming, meanwhile, focused on writing single programs to be reproduced in two clearly separate and meaningfully different, yet epistemologically equalized forms: the virtual object destined for execution, and a typeset document intended to be read as an essay. That Knuth manages this without losing sight of the distinguishing characteristic of programming as automation, the bête noire of all humanisms—indeed, while defining computer science itself, paradigmatically, as the study of what can be automated—is still more remarkable, both as rhetoric and as thinking. More recent projects in a similar spirit, including Cristina Videira Lopes’s two editions of Exercises in Programming Style and Angus Croll’s lighthearted but not unserious If Hemingway Wrote JavaScript (2014), can be understood as variations of Knuth’s specific disposition of literate programming as truly conjoining these two domains, rather than merging one into the other.19
Second, and more basically: individual disciplines and major clusters of disciplines exist for historical reasons. Which is not at all to call individual disciplines, major clusters of disciplines, or the concept or system of disciplines itself outdated or obsolete. On the contrary, this is rather to observe that their borders are not simply imaginary—merely willed, as it were, and thus arbitrary, even when we creatively exceed them, as some of the figures I mention here did from the engineering side of the border, and as I hope to have done within philology understood as an enclave.
Finally, a word about Mark C. Marino’s Critical Code Studies (2020), a study whose specific orientation toward the literary humanities may leave it seeming closest to my own. To begin with where we agree: I fully share and heartily endorse Marino’s conviction that “if code governs so much of our lives, then to understand its operations is to get some sense of the systems that operate on us. If we leave the hieroglyphs to the hierarchs, then we are all subjects of unknown and unseen processes” (Marino 2020, 4). Leaving aside the likelihood that we will still be the subjects of those processes even if we see and know them, I agree with Marino that cultivation in this area can make a difference. I also see value in “critical code studies” as devoted, in Marino’s description, to reading computer programs with primary attention to meanings “locked in their technosocial context” (Marino 2020, 4).
In other words, we agree on the urgency of both these things: a general ability to read program code, and a specific ability to read it in a context meaningfully exceeding the strictly technical and self-referential. I take Marino’s side in some disagreements with other scholars, as well. For example, I share, albeit much more strongly, Marino’s relatively mild antipathy to the argument that program code is language: or paraphrased charitably, that writing in a programming language is similar enough to writing in a natural language that the promise of their imaginary affinities ought to outweigh their actual differences. Unfortunately for such excitable speculations, code is not language—full stop. And as Marino also argues, code is not poetry, either: or paraphrased charitably, there is nothing of particular value to be gained from excitably minimizing their differences or from conflating them outright. Most program code, Marino puts it correctly if perhaps too patiently, “is worlds away from literature, film and visual art” (Marino 2020, 49–50).
There are, however, significant differences in our approaches. On the one hand, Marino emphasizes, as I do, the learning of programming languages. On the other hand, Marino cites approvingly (Marino 2020, 46) Rita Raley’s speculation, in an essay published eighteen years before Marino’s book, about the prospect of programming languages meeting foreign language requirements in university humanities curricula.20 Marino’s approval of this idea is difficult to reconcile with his resistance to its implications elsewhere in the book, as noted above. Setting aside the question of whether Raley would take precisely the same position today, in the eighteen years since Raley’s remarks first appeared in print, substitutions of programming languages for foreign language requirements have seldom gained traction, notwithstanding the encouragement provided by right-wing legislators and liberal centrist technocrats alike, with the backing of Silicon Valley edupreneurs. While part of the reason for the slow uptake here may be simple inertia, there are other reasons as well. Once again: code is not language, full stop.21
Let’s say that an ambitious researcher in computer science, who cannot read German, finds that they need to learn German to read a small or historically obscure corpus of research in mathematics or engineering that promises to be useful to their work. By what logic could, or should, a researcher in the humanities learn the Java programming language for a supposedly analogous purpose? No one has ever written scholarship—or anything else, except programs—in Java. As a related question, should a serious researcher in computer science, or any other information technology–related field, be relieved of the requirement or the incentive to publish their research results in papers, reports, articles, or books—and simply publish undocumented programs instead? Most researchers in those fields would find this idea absurd. It makes perfect sense to require students to learn both foreign languages and programming languages, but not to substitute the latter for the former.
A more fundamental difference in our approaches is that while Marino emphasizes the learning of programming languages, it is ultimately a glancing emphasis, which Marino qualifies immediately by appeal to the unnecessarily embellished concept of “cyborg literacy”—meaning a state of affairs in which humanities researchers collaborate with other researchers who know programming languages, rather than learning programming languages themselves (Marino 2020, 46). Because research in the humanities is never urgent, I see no benefit in such arrangements. They might be fun, sometimes, but they’ll never be necessary, and there will always be time for the would-be cyborg to just do their homework instead. Overwhelmingly, Critical Code Studies, the book and the new research field that Marino imagines launching with it, aims to correct the preferential attention generally given to software over code, and while I have my sympathies with this project, in the end what Marino calls code is an abstraction. As Marino uses it, but without acknowledging this issue consistently, the word code, properly speaking, always refers to text written in a particular programming language—not any programming language at all, or all programming languages at the same time. And the concept corresponding to the word “code” abstracts the specificity of that particular programming language, whatever it may be, much as the word and concept “language” itself, as we normally use it, abstracts the specificity of English, the language of publication of this book, or of any other natural language.
In other words, for Marino the rightful and corrective focus should be on code. For me, it is on programming languages. That, more than anywhere else, is where we diverge. As I see it, Marino separates the idea of “reading code” from the learning of programming languages in order to present code as another kind of readable text, in kinship with other kinds of readable text. This is a rather exhausting and possibly exhausted habit in the literary humanities, particularly in the inflection lent it by the enormously influential work of the German literary critic Friedrich A. Kittler, who is cited abundantly in Critical Code Studies. Of Kittler’s obsessive, career-long deposing of literary language, his insistence that code can, may, does in fact compete with literary language, specifically, and will someday usurp it, it must be said: though its pretense is to almost precisely the opposite, this is, knowingly or otherwise, more than anything else an attempt to enclose and enfold code in the study of literature—to ensure the continuity of the study of literature first of all. In its intellectual debts and its bibliographic world view, Marino’s book is in this way narrowly grounded, indeed cemented in a single, media-oriented corner of the literary humanities, despite its interdisciplinary ambitions.
My return to philology, as a reset or re–starting point for the study of programming languages, is not a recuperation of programming languages to the humanities generally, let alone to the study of literature specifically. To do that is to leave oneself unable to acknowledge the most fundamental characteristic and purpose of programming languages in their own context, the context in which they were originally developed and in which they continue to be used today. Whereas for Marino, “code since its inception has been a means of communication” (Marino 2020, 17), for me programming languages always were and are first of all systems of automation. Finally, in explicitly distancing “critical code studies” from Donald E. Knuth’s concept of literate programming, Marino dramatically underreads and underestimates Knuth’s work on that topic, reducing it to a discourse about the “readability” of code, which it certainly is not (Marino 2020, 41). In sum: Marino rejects the conflation of language and code, while also tolerating it. I simply reject it. Marino focuses mainly on code, and views code as communication, while I focus primarily on programming languages, and view them as systems for automation. Marino positions code in the narrow purview of the twentieth-century literary humanities, while I look back to the origins of philology for a broader perspective, one that includes the humanities but isn’t enclosed by them.
IV
My approach is broadly philological in three distinct senses of that term, none of them reducible to its quotidian associations with either historical linguistics or literary historiography. First, it emphasizes the histories of both natural and formal languages, including programming languages, in their individual specificities, over their abstract formal or structural characteristics—if not as more important than the latter, then as equally interesting and deserving of attention. Second, it regards individual natural and formal languages as carriers and sometimes shapers of (specific) cultural histories. Third, it aims to integrate knowledge from different disciplines without rejecting the difference of disciplines, imagining that difference a mere artifact of bureaucracy, or demanding that that difference be discarded or overcome.
Historiography and philosophy have always dominated humanities-based research on computing, but philology is neither philosophy nor historiography. And the history of this word, as Margaret Alexiou has noted, is marked by “a steady erosion of its wider” meanings (Alexiou 1990, 56). In ancient Greek, where it was distinguished from philosophy as the love of wisdom, philology encompassed the love of argument, the love of reasoning, the love of learning, the love of learned conversation, and the love of literature (Alexiou 1990, 56). In modern Greek up to the eighteenth century, it was an equivalent of Latin litteratura, “inclusive of all kinds of writing (history, theology, philosophy, even the natural sciences)” (Alexiou 1990, 56). Its first recorded use in English, in the seventeenth century, was similarly wide in scope, meaning love of learning in general, love of literature and rhetoric generally and literature in particular (Alexiou 1990, 56). Later English usage significantly attenuated its range of meaning, narrowing it to historical linguistics or a “science of language,” while in German its scope expanded again, acquiring an association with so-called writing systems: assemblages of the alphabetic, syllabaric, or logographic modes, forms, and appurtenances of spoken languages.
Even in this context, the consilience of German philology has been understood as consonant with a scholarly practice that is even older than ancient Greece. “It is generally assumed,” Michael Holquist has written, “that the first writing system is found in cuneiform tablets unearthed in the city of Uruk 11 dating roughly from 3200 BCE. Sumerian, the language represented in these tablets, died out as a spoken language early in the second millennium. [ . . . ] The priests and scholars who kept the wisdom of the Sumerian past alive in the second millennium BCE are the first philologists” (Holquist 2011, 269–70). This formulation, which describes philology as the study of writing systems as mediating affordances for the transmission of knowledge, suggests that philology is, paradoxically yet not nonsensically, both broader and more focused than historiography. It stands not only for the historiography of writing systems, specifically, but for the study of writing systems’ mediations of knowledge, including their mediations of the reflective temporal dimension of experience we call history and its formal study as an object by the practice of historiography. Historiography, the writing of history, can only be performed using a writing system—in a natural or human language. Philology includes the study of the writing systems used to perform historiography, as historiography itself does not.
Before it is anything else, a programming language is also a writing system, albeit for a formal language rather than a natural one, and software is written text before it can be anything else. It follows that a historiography of programming languages uses one writing system to describe another, but without reflection on that bipartition or bicamerality itself. That reflection, I suggest, is the task of a philology of programming languages.
So, philology is not historiography. Neither is it philosophy, which separates itself from historiography more completely. In its broadest meaning, philology already includes philosophy, as it includes historiography. Indeed, philology stands comprehensively for a general cultural secularization within which historiography emerges as a rival of myth, while philosophy challenges theology and religious authority. Too, it stands against what Pieter Verburg, writing of the nineteenth-century German comparative linguist Franz Bopp, called “the direct interference and arrogance of philosophy in matters of language” (Verburg 1998, 461), or philosophy’s abstraction from the writing systems used to perform philosophy. As Sheldon Pollock put it:
Philology is [ . . . ] the discipline of making sense of texts. It is not the theory of language—that’s linguistics—or the theory of meaning or truth—that’s philosophy—but the theory of textuality as well as the history of textualized meaning. If philosophy is thought critically reflecting upon itself, as Kant put it, then philology may be seen as the critical self-reflection of language. (Pollock 2009, 934)
In the philosophy of media, the philosophy of technology, and the philosophy of software, philology resists the philosophical obfuscation that subordinates technical knowledge to its enclosure or enfolding in something else. In the influential work of the French philosopher Gilbert Simondon (1924–89), this tendency, designed to ensure the primacy or the supremacy of philosophy, is itself an example of “culture [ . . . ] as a defense system against technics,” the object of Simondon’s own critique (Simondon 2017, 15). Simondon’s grandstanding denunciations of an ignorant or resentful “facile humanism” that fundamentally misunderstands machines (Simondon 2017, 15–16) served as the rhetorical furniture of a crypto-humanism that isolated and elevated philosophy as an envelope for technics:
It is only at the level of both the most primitive and the most elaborate of all thoughts, philosophical thought, that a truly neutral or balanced because complete, mediation between opposing phases can intervene. It is thus philosophical thought alone that can assume the knowledge, valorization and completion of the phase of technicity within the entirety [ensemble] of man’s modes of being in the world. (Simondon 2017, xvii, emphases in original, translator’s interpolation in original)
To be clear, Simondon was entirely correct to identify technical ignorance of computing as a serious and urgent practical, intellectual, and sociopolitical problem. I second Simondon’s imagination of an effective “cultural reform” in general education and knowledge of technics, as a prelude to effectively regulating technics (Simondon 2017, 19, 21). However, I do not share or condone its motivation. It should not be part of a project to assure the primacy or the supremacy of philosophy. This is a powerful tendency and an entertaining pastime in the literary humanities, now as it was then. But it is not an effective one. Philology is a distinct mode for the analysis of the textual dimensions of computing as a research object in itself, and of programming languages in particular—as contrasted, for example, with computing’s mere use as a research tool. In this role I believe it is more effective than philosophy.
Lest this be mistaken for a so-called postcritical approach to the topic, let me be clear that my point of reference and point of departure, here, is the revival of philology as counter-Enlightenment by literary humanists such as Edward W. Said, Paul Bové, and Aamir Mufti, among others, whose scholarship has always combined and balanced erudition with critique.22 Nothing could be further than “postcritique” from my intellectual affiliations in general or my goals in this book, and while unlike my previous work, this book contains almost no polemic, the framings and endpoints of the stories I tell in each chapter make their critical commitments clear. For me personally, the relevance of the work of Bruno Latour, for example, is disqualified by the fantastically delusional and opportunistic essay “Why Has Critique Run Out of Steam? From Matters of Fact to Matters of Concern” (Latour 2004), and the same applies to the American anticritical movement that rode Latour’s coattails for the two decades marked by the invasions of Afghanistan and Iraq, the reorganization of the US economy around new platform monopolies, the saturation of US culture by the priorities of libertarian Silicon Valley, and the far-right authoritarian populism that emerged from a toxic stew of resurgent jingoism, unreflective libertarian and centrist liberal technocracy, and the algorithmic operationalization of likeness and reciprocal amplification as principles, indeed conditions of social relations. Preferring it to Latour’s superficially similar, but to me at least, politically incoherent ideas, I have informally, nonprogrammatically, and nonpedantically adopted Simondon’s imagination of technicity in ensembles in a loose, secular mode divorced from the philosophical obfuscation that it carries in Simondon’s work.
In its focus on language, philology describes the way that power is wielded through and in language. While programming languages are codes, not languages, perhaps we wish to misconstrue them as languages because they are sites and applications of power in similar ways. Software is created using programming languages, full stop. There is no other way to do it. And both the designs and the usage cultures of programming languages reflect the often enormously privileged positions of those who created them and who use them to earn outsized, sometimes outrageous wages. At the level of designed characteristics, a programming language that optimizes for speed, efficiency, and type safety over other qualities, like approachability, convenience, and ease of use, may reflect the priorities of a specific context of privilege, such as financial, scientific, and military applications of high-performance computing. At the level of designed applications, programming languages designed for data analysis and so-called machine learning, rather than for the building of websites and small applications or for creative and expressive applications of computing, may find their niches in technological infrastructures that automate extractive and punitive surveillance or actuarial, judicial, and carceral deliberation. And so on. Specific programming languages (some more than others) serve as access keys to such domains. The autologies or technical self-references and self-referentialities of programming language cultures, which are their default states, abstract away such considerations, while a philology of programming languages restores them to view.
V
With varying degrees of explicitness, this book makes the following three arguments:
1. Technical ignorance of computing is a practical, intellectual, and sociopolitical problem.
It is a practical problem because it ensures dramatically greater exposure to harassment, abuse, and crime facilitated by insufficiently understood personal information security principles, including but not limited to routine, unavoidable quotidian procedures like choosing passwords and configuring a home network router.
It is an intellectual problem because it encourages even the highly educated, such as professional academic researchers, to journalistically reproduce technology industry hoopla and meme engineering. A general example is the catachrestic abuse of the word digital in such phrases as “digital scholarship” and “digital humanities.”23 A more specific example is the combined panic and glee that greeted OpenAI Inc.’s first offer of web-based public access to its ChatGPT product, in December 2022.24 Intellectuals are persons temperamentally unable to refrain from commenting on any apparently important issue, and even today most of their remarks on computing do more harm than good. It is reasonable to suggest that the rollout of ChatGPT and an accompanying highly orchestrated publicity storm reflects tech industry panic in the face of declining material fortunes on top of declining hegemony, and the credulity with which the commentariat consumed and amplified this event would be fairly described as conditioned to a so-called Pavlovian degree. The issues of surveillance, data privacy, data bias, and the automation of labor remain areas of persistent intellectual weakness and uncritical thinking, even among those who proudly parade their new interests in them, and an emerging stampede, at the time of writing, toward “critical artificial intelligence studies” unwisely accepts the inaccurate, but entirely industry-friendly canard that the emergent or generative behavior of so-called AI technologies takes place in so-called black boxes, at least partly inscrutable even to their creators. Despite my antipathy to Simondon’s crypto-humanism, as I have characterized it above, I acknowledge that Simondon’s philosophy of technology is grounded in technical realities and technical details. This is better than nothing. We can distinguish such an approach from the Heideggerian tradition of the philosophy of technology, in which the supremacy of philosophy is a goal and a purposive distraction from technical realities, rather than a shortfall of the effort to understand. At the time of writing, OpenAI’s ChatGPT and its siblings and competitors, including Microsoft’s Bing and Google’s Bard products, are still widely described as “AI technologies” even by those who should know better. Ontologically speaking, these products are not in any meaningful way artificial intelligences, or even, with slightly more technical accuracy, neural networks or large language models (LLMs). Rather, they are software operating on data—and software consists only of code in identifiably specific programming languages, full stop. Any real understanding builds from the bottom up here.
Finally, it is a sociopolitical problem. To explain the relative instability of the major forms of democratic political organization today in its appropriate context and scope—that is, world economic and social history—is a far larger undertaking than my undertaking here. Still, it is a mistake to construe the social manifestations of that instability that most of us have observed in our daily lives, in recent years, as the products of partisan or “polarizing” rhetoric in themselves. Rather, they are products of algorithmic operations performed on instances, iterations, and accumulations of speech of those types, which amplify their reach in several different ways. On an individual level, even a modest technical understanding of the recommender systems at the core of the vast software infrastructures of Facebook, Instagram, Twitter, YouTube, and other notably destructive social media platforms can help users of such platforms shape our usage so that they remain tolerable to use, if we wish to continue using them. At a systemic level, some meaningful technical understanding will be indispensable to effective regulation of such platforms by legislators and to encouraging and expanding such regulation through activism.
2. Automation is not a myth.
Writing in the 1950s, an era when French intellectual culture was both overtly and covertly fascinated by cybernetics, the French philosopher Gilbert Simondon (mentioned above) opined with supreme confidence that “pure automatism, excluding man and aping the living, is a myth that does not correspond to the highest level of possible technicity: there is no machine of all machines” (Simondon 2017, xvi). Simondon had contempt for “worshipers of the machine” who imagined “that by increasing and perfecting automatism one would manage to combine and interconnect all machines among themselves, in such a way as to constitute the machine of all machines” (Simondon 2017, 17). But one might say that his entirely sensible resistance to such excitable speculations left Simondon unprepared or unable to recognize the fundamental logic of computer programming as the automation of automation, which was being attentively and accurately described at the same moment by Grace Murray Hopper in the United States (see my extended discussion in chapter 1). Measured against Hopper’s technically precise and sociologically insightful observations about the ongoing automation of programming itself, Simondon’s characterization of “automatism” as “a rather low degree of technical perfection” (Simondon 2017, 17), and his insistence that “automatism, and its utilization in the form of industrial organization, which one calls automation, possesses an economic or social signification more than a technical one” (Simondon 2017, 17), seem mistaken at best and philosophically evasive or sophistic at worst. When James Martin observed in Application Development without Programmers that “the number of programmers per computer is shrinking so fast that most computers in the future will have to work at least in part without programmers” (Martin 1982, xv) lest “the entire American workforce [ . . . ] be needed to program its computers” (Martin 1982, 2), the apparently economistic reductio ad absurdum of these remarks was in truth a basic observation about the technical logic of software as automation. We have never needed, and we will never need, everyone to learn to program computers, if only because the purpose of programming computers is to relieve us of the tedium of that activity itself.
Indirectly and directly, in forming my arguments here, I have also drawn on three studies published in the last quarter-decade, two having been published very recently. These three works, located in economic historiography, economic sociology or political economy, and digital cultural studies, respectively, all represent direct engagements with a recent or longer history of both public and expert discourse about automation during the nineteenth and twentieth centuries. In Inventing Ourselves Out of Jobs? America’s Debate over Technological Unemployment, 1929–1981 (2002), Amy Sue Bix recapitulates “the history of technological unemployment talk in the United States” (Bix 2002, 8) with its antecedents in nineteenth-century debates on the other side of the Atlantic triggered by the mechanization of manufacturing. Aaron Benanav’s Automation and the Future of Work (2022) critiques a resurgent or new “automation discourse” that emerged in the 2010s across the entire US party and extra-party political spectrum in response to the historically most recent and legible manifestations of “chronic labor underdemand” (Benanav 2020, x). Similarly, and with the same critical targets in view, Luke Munn’s Automation Is a Myth (2022) declares that the notion of “full” automation is a fantasy and “a long-running fable about the future of work that needs to be reconsidered” (Munn 2022, 2).
Though the first of these works is a sober historiography and the second and third intellectual-political polemics, all three focus centrally on discourse, even when they support their rhetorical analyses, sometimes extensively, with reliable economic data. That often extensive support does not as often extend to technical realities, however, which means that all three risk imagining automation, at least for their readers, as more a discourse than anything else. But the fact is that software automation, specifically, is a specific technical reality, with a specific technical logic that deserves recognition. This does not mean that Programming Language Cultures: Automating Automation is not also fundamentally a cultural study, like the three works I have just mentioned here. However, as a study of programming languages as cultural artifacts, this book does give special attention to the specific technical logic of software as automation, a topic that each of those other three works largely elides, each for its own reasons.
In 2021, a year before OpenAI released the product it calls ChatGPT, best described as a consumer-friendly web interface and API (Application Programming Interface) to a software system that generates natural-language prose in response to natural-language prompts, the company released a similar product named Codex, designed to write code in widely used programming languages. While the public reception of Codex was considerably quieter than that of ChatGPT, its long-term impact can be expected to be far greater, given that the natural-language output of ChatGPT has a more limited range of truly plausible long-term and lasting real-world applications. Because the purpose of software is first of all automation, computer programmers have always worried, entirely reasonably, that they will invent themselves out of their jobs. While the adoption and integration of Codex and similar systems into the production of software may be unlikely to threaten the jobs of the most elite and highly skilled programmers, especially those who program these systems in the first place, if such systems prove persistent and durable there is every reason to expect them to impact job availability and wages for entry-level and moderately skilled programmers and those whose specializations are no longer in demand.25 If one asks the ChatGPT system to assess the likelihood of such developments, one receives an answer carefully crafted to minimize controversy: for example, “In fact, one of the main goals of Codex is to augment and enhance the work of human programmers by automating repetitive or mundane tasks and providing intelligent suggestions and insights.”26 Because the work of human programmers already is, and always has been, the automation of repetitive and mundane tasks, with the definition of “repetitive and mundane task” constantly being shifted forward, this will be transparently cold comfort to any programmer who grasps the fundamentals of computing. The software-computational problem that still requires human ingenuity today is always becoming the repetitive and mundane task of tomorrow. That is how software development works. ChatGPT’s answer on behalf of its sibling product is an excellent illustration of the logic of the automation of automation, or layered, even recursive automation.
3. Automation is a moving target.
In line with Munn’s (2022) more considered, less rhetorically charged arguments that automation is always incomplete and unevenly distributed (which I discuss in chapter 6), an overt assumption of this book is that automation is a moving target rather than something that has been completely achieved. Three factors are pertinent here. First, general technological progress is ongoing, if slowly and steadily rather than dramatically, and this means that the scope of software automation, specifically, will continually expand even if it never reaches the “fullness” of completion or totalization. Second, automation requires constant maintenance. Software automation is buggy, in the first instance, and quickly becomes outdated, even with attentive maintenance. However, this does not obviate the technical logic of software as the automation of automation. Any insistence otherwise is likely to be driven by excessive rhetorical and ideological investment in the “resistance in the materials” being automated. What it does mean is that in line with broader refinements of technology in general, any software automation needs ongoing development to remain viable. Even a task that appears to have been fully automated still requires attention, in this sense. Third, automation has both immediate and longer term economic, social, and political impacts that influence the scope of its implementations and applications, which may advance, recede, or withdraw entirely in some cases, depending on circumstance. Increased productivity and efficiency is one side of the coin, while technological unemployment and social disruption is the other. Nothing is inevitable here.
Notes
1. A passage in this introduction originally appeared in “Program Resumed,” an interview published by the Johns Hopkins University Press blog, Newsroom, on March 28, 2018.
2. See Cortada (2004), Cortada (2006), and Cortada (2008).
3. For the claim that 220 billion lines of Cobol are still in use today, see “COBOL Blues” (n.d.). See also Cassel (2017) and “Did COBOL Have 250 Billion Lines of Code and 1 Million Programmers, as Late as 2009?” (2017).
4. See Ford (2015), Nguyen (2015), and Somaiya (2015).
5. Elon Musk, whose opinions still carry weight even if at this point, they’re the equivalent of a stopped clock that tells the right time twice a day, recently opined that “too much talent is chasing software” in the tech industry and more generally, calling it a “major misallocation of capital.” See Tangermann (2023).
6. For a journalistic perspective on this point, see Merchant (2018). As I acknowledge at other points in this book, mine is a generalizing and generally looser usage of the term “recursion” than a strictly technical perspective might permit. That is deliberate, not accidental.
7. See especially Fuchs (2014), Fuchs and Mosco (2016), and Fuchs (2016), but also Terranova (2004), Bellucci (2005), Scholz (2013), and Scholz (2017), among others.
8. See Light (1999), Campbell-Kelly (2004), Grier (2007), Ensmenger (2010), Abbate (2012), and Hicks (2017), among others (and before them, Kraft [1977] and Greenbaum [1979]). For a useful survey and evaluation of what the author calls the “sociology-of-work literature in this field,” including studies published by Fred Block, Alvin Gouldner, Larry Hirschhorn, Rosabeth Kanter, Michael Piore and Charles Sabel, Alain Touraine, and Shoshanna Zuboff, whose early work optimistically counterposed “informating” to “automating,” see Burris (1993, 16–18).
9. See Williams and Srnicek (2013).
10. As examples of work in these areas, see Benjamin (2019), Berry (2011), Bratton (2015), Chun (2013), Evens (2015), Franklin (2015), Frabetti (2015), Golumbia (2009), Golumbia (2016), Hui (2016), Noble (2018), Sack (2019).
11. See Mackenzie (2006).
12. A partial exception is Montfort et al. (2013), seven of the eleven main chapters of which focus on the BASIC programming language. Only one of these seven chapters could reasonably be called a study of the BASIC language, however, with the remaining six devoted to explaining very simple command sequences and very brief programs to readers who are assumed to have no knowledge either of BASIC or any other programming language. The book’s eighth main chapter, titled simply “BASIC,” does discuss language design and syntax variation in some detail, but is otherwise given over to reviewing BASIC’s implementation and usage history, again for a reader assumed to lack elementary knowledge of the subject. As of this writing, 10 PRINT CHR$(205.5+RND(1));:GOTO 10 and Marino (2020) are the only book-length publications to have emerged from “critical code studies,” an undertaking that Marino (2006) attempted, laudably if probably unsuccessfully, to distinguish from a more media-oriented “software studies” almost two decades ago. As for the more general “digital humanities” movement, its inaccurate but fundamental premise, that humanities scholars are uniformly newbies to technical aptitude and training in programming, leaves it unfit for advanced research in this area. Those few self-identified digital humanities scholars who do write programs in R and Python, for example, for their work are applying these programming languages as tools for research automation, not studying them as research objects in themselves. In short, when digital humanities scholars were presented with the opportunity to study programming languages as cultural artifacts relatively closely aligned with their training and expertise, they chose instead to become the world’s most incompetent and bumbling research programmers. See Swafford (2015), Da (2019), and Levy-Eichel and Scheinerman (2022).
13. See Sammet (1969), Knuth and Pardo (1976), Wexelblat (1981), Bergin and Gibson (1996), Bergin (2007).
14. The “politico-social history of Algol” promised by Bemer (1969), for example, turns out to be a bibliography with abridged extracts from various primary sources (letters, meeting minutes, committee resolutions, and so on), many relating to the famously fractious negotiations of the specification of Algol 60 in particular. It is that history of conflict to which the term “politico-social” presumably refers; still, this document is entirely descriptive and offers no analysis whatsoever.
15. See Light (1999), Grier (2007), Abbate (2000), Abbate (2012), Ensmenger (2010), McIlwain (2020), Shetterly (2016), Hicks (2017).
16. See Lennon (2013).
17. See Ames (2019).
18. See Felleisen et al. (2018).
19. See Lopes (2014), Lopes (2021), Croll (2015).
20. See Raley (2002).
21. Another similarly approving citation, equally difficult to reconcile with Marino’s rejection of the conflation of language and code, is that of Geoff Cox and Alex McLean’s programmatic pastiche of code with speech (Marino 2020, 12). Again, for me this is a nonstarter. See Cox and McLean (2013).
22. See Said (2004), Bové (2009), and Mufti (2010).
23. “Social historians,” Haigh (2014) observes, “have done a great job examining the history of ideas like ‘freedom’ and ‘progress,’ which have been claimed and shaped in different ways by different groups over time. In the history of the past 60 years ideas like ‘information’ and ‘digital’ have been similarly powerful, and deserve similar scrutiny. If I was a ‘digital historian,’ whose own professional identity and career prospects came from evangelizing for ‘the digital,’ could I still do that work?” (Haigh 2014, 28). For a sociological analysis of catachrestic usages of the word “digital” more generally, see Sweeney (2015).
24. On the initial reception of ChatGPT in higher education, see the summary articles by McMurtrie (2022) and Warner (2022).
25. In August 2023, only two years after acquiring coding bootcamp Kenzie Academy, Southern New Hampshire University decided to close the program. A spokesperson suggested that the potential impact of LLM-powered automation, on either demand for such programs or their outcomes (or both), was a factor: “Lopez [ . . . ] said the ‘exponential’ adoption of artificial intelligence played a role in the decision to end Kenzie. ‘The world is changing fast, and we, like many institutions, are thinking about the ways AI will impact education in profound ways that are just starting to take shape,’ she said.” See Coffey (2023).
26. The text quoted here was generated on March 7, 2023, in response to the prompt “How likely is it that adoption of Codex will reduce demand for human programmers and software engineers?”