Is code a performative speech act?

Computer processing is the act by which the world of the computer is constructed. We can call it a world because it appears to exist unto itself, persisting its environment and taking scripted actions well outside of our awareness. Modern computers rarely shut off completely, so the illusion of persistence (“my user desktop is still there even when my computer is asleep; I just drop in on it now and then”) is not entirely an illusion. And in the overlapping world of the Internet, availability is a given: it is prioritized by server providers and taken for granted by users. We expect that Google is still there when we’re not looking at it—we behave as if it’s there even when nobody is looking at it.

^{It may not be technically accurate to assume that a website exists when it’s not being viewed. Our experience of a website is not what is stored on physical media (code and data) but rather an opinionated interpretation of it by another application. If we were to routinely experience the part of the website that literally persists between viewings we’d get considerably less value out of the web.}

We can also define the computer as a world because it is separate from our own in well-defined ways. A command spoken or action taken that does not target one of the extremely constrained inputs of the computer will have no effect on its world, and an event within the world of the computer has no effect outside of it unless it crosses the threshold of one of its extremely constrained outputs. (Sometimes computers catch fire but that’s the result of physical processes outside the computer’s world, even if they respond to processes inside it.)

All of a computer’s behaviors are described by hardware (the material facts of electronic chips and cables) and software (the instructions stored as data on the computer and purpose-built to trigger behaviors in its hardware). Coding is the act of creating software. So it’s reasonable to ask, is coding a purely performative speech act? Here I’m referring to J. L. Austin’s theory of the “speech act,” something that is spoken not to describe reality but to change it. Classic examples include “I do” in the marriage ceremony or “you’re fired” in the workplace. When we speak those phrases we are not simply communicating information about the way things are; we are making things substantially different—speaking a change into existence.

Of course, speech acts are not restricted to speaking aloud. “Speech” here means the same thing as in “free speech,” so the definition includes anything that is spoken, written, signed, painted, or danced. And it is by the definition of free speech that we can affirm part of our premise. Computer code is free speech; this was affirmed by courts in the United States in 1996 and again in 2001. If it is free speech, it must be speech.

Yet code is different from other forms of speech because, at least in the platonic ideal, its meaning is deterministic. Programmers write code that targets a compiler, an interpreter, or sometimes a chip. And in the context of that target the code has a single, eternal meaning. The programmer is generally not perfectly aware of that meaning—this is the origin of bugs—but the meaning is static nonetheless as long as the context does not change. The computer does not filter code through the lens of experience or social dynamics or emotional awareness. It cannot bear ambiguity. The code defines a very specific set of behaviors or else nothing.

So at first brush it seems that code is performative speech: it does things. However, it could also be argued that code is entirely non-performative—that it’s 100% descriptive. After all, the act of writing code does not itself have an effect. If I write code on a piece of paper and shred it, it doesn’t really matter what behaviors the code indicates. Likewise if I write code in a computer file but never execute it, there is no effect. It’s the act of running code (assuming significant acts by the computer to parse, compile and process it) that actually performs.

Nonetheless, we have to accept that writing code without compiling or running it is still coding. One does not always have the convenience of writing code in the presence of something that can immediately understand it. In less-than-ideal situations, we have to send our code to a remote device or person who will run it. They are not coding; we are coding. They are simple executing what we have already coded. How can our code be a performance if we are detached from the gatekeeper of its effects?

This argument makes sense until we apply the same argument to non-code speech. Language doesn’t take effect unless it’s received, interpreted, and acted upon. “I do” isn’t a valid oath of marriage if spoken in a language nobody understands. “You’re fired” doesn’t terminate someone’s employment if shouted in an empty room or by someone who doesn’t have corporate power. In either case the statement might be written on a piece of paper and presented later without losing validity. Speech is performative in the moment it’s accepted. Linguists have disagreed as to whether the social or linguistic context is more important, and to be fair, one can make oaths to oneself or quit a job without the acquiescence of one’s boss. But the audience still exists—to be one’s own audience is not to speak without an audience.

Code appears not to fit the concept of self-directed performance. Perhaps simple code could be written and then followed, line by line, by a human acting the part of a compiler. But this is subversion. The code would become a recipe, not an application. The human would inevitably attach meaning and actions to the code that aren’t part of its literal meaning. This is what makes code unique among speech acts: the fact that it has a literal meaning at all, one that can be unambiguous in a particular context. Not even the strictest legal contract can transcend human interpretation. Code does this almost always. In this way it’s more like math than writing.

It should be conceded that computer hardware is designed and (indirectly) built by humans, who even with strict mathematical parameters are constrained to produce ambiguity. It may not be true at the level of infinite detail that all code is completely unambiguous before it runs. For example, it’s often necessary to run a piece of code hundreds or thousands of times to benchmark its performance; any one execution may be several milliseconds slower or faster than the median. Where code stands out, though, is that its interpretive context can be understood to be unambiguous, even proved using formal logic, whereas with natural language in a social environment this is impossible.

Code, then, is a speech act. It is a performance upon the world of the computer. But is it purely performative? There is a second context within which we can argue it is not.

In Structure and Interpretation of Computer Programs appears the oft-quoted line, “Programs must be written for people to read, and only incidentally for machines to execute.” This mantra makes sense if taken non-literally, as an exercise for the programmer’s mind rather than an explicit goal. Code rarely, maybe never, fulfils its purpose unless it executes successfuly. But the character of a piece of code can’t be fully described in machine terms. It has never been the collective fortune of software programs to be written once, compiled, and never seen again. Rather, they are written, tested, tweaked, shared, collaborated upon, and continually re-interpreted by human beings until the end of their useful life (or almost). In this way, a computer program is less like a spell cast upon another world than a description of some mundane process that’s important for another programmer to understand in painstaking detail.

Said another way, to describe a program only in terms of its effects ignores the unlimited means and variations by which those effects can be had, and each variation carries a meaning that is apparent not to a machine but to another person. By naming various identifiers in oblique ways, we could reproduce the collected works of Shakespeare in a program that merely adds numbers together. To do so would be absurd. Yet it’s hard to deny that a message would be taken from such a program beyond and aside from the literal facts of its operation.

So it is not only the compiler that listens to us when we speak in code. It is ourselves and our fellow programmers. On GitHub, it may be an audience of millions.

Even when a program is written by a lone programmer, compiled in a way that removes any ambiguities or stylistic choices, and distributed directly to end users, its value is rarely exhausted by simply executing it. Software is interactive. The story of the program is not in the bytecode itself but in the way you use it. I mean this literally and concretely. The program may be following algorithms, moving data around in memory, and calculating values, but this is not something the user experiences directly. The effect of those actions on the real world is intangible above the quantum level and ineffectual by any standard. They must be interpreted first by a computing context, second by a peripheral device (such as a monitor), and third by the user. When they are communicated to the user and understood, that is the moment where the software has had an effect. Typically this becomes a game of back-and-forth between user and machine, the software accomplishing highly predictable tasks at the user’s direction and the user accomplishing more abstract tasks under the principle of a preexisting process, which may in turn be framed or enforced by the software.

To use software is to receive an idea. An accounting program is an automaton that describes an accounting process. A video game expresses a way of interacting with a problem or environment. A media player teaches us a way to watch videos: here is a frame to look within, here is a button that will pause the video while you take a leak.

So, then, a computer program is less a speech act and more a communication. I write code not to act upon you unilaterally, in a position of sovereign authority, but to communicate with you and allow you to respond to me by proxy. Even the software that autonomously instructs rollers and mechanical arms on an assembly line is fundamentally a transfer of information. It performs calculations in a digital environment and produces signals; with luck, they receive those signals and perform actions in the real world. As with any software, there is a boundary between worlds that must be crossed.

It may even be argued that a computer program can’t be conceived as a speech act without robbing the phrase of all meaning. When we arrange and manipulate computer memory in order to carry a message, is that so different from the way we arrange and manipulate the molecules around us when we produce sound by speaking? All speech would be performative if we counted the creation of compression waves in a medium or the reflection of photons. But we do not. We use the phrase speech act as a way of categorizing some speech as different from other speech. So even if it’s true that within the constructed world of the computer, code is purely performative, it’s equally true that in the natural world it isn’t.

The obvious question here is, “what if I write a computer program to inform an employee that they’re fired?” Of course code, like any other form of expression, can be the medium for a speech act. (It cannot ever be the agent of it.) This program is a performative speech act, but it is not purely performative. No speech act between two people ever is.

As a tangent—this cuts at a question that’s frequently discussed in the context of self-driving cars. If a computer drives a car into a person and injures them, who is at fault? This is a performance on the natural world; the fact that it’s mediated by code makes very little difference. One answer is “whoever had the intrinsic authority to navigate the car in the first place.” This places blame on the owner, assuming the car can also be driven by hand. But a more insightful answer is that since the owner gave up their authority to the autopilot, the blame rests on whoever told the car (immediately or by proxy) to drive in that direction and at that speed. This implicates not just a single programmer or team, but likely an entire corporation. The car and its code are mere tools. The people that produced it are its operators, however distant. Their authority to act on the world is proven by the effect of their instructions. No other origin exists.

Even in the context of artificial intelligence there exists a natural origin for any act. Artificial intelligence is an algorithm that acts on patterns. The algorithm is selected by a person, the patterns are designated by a person, and the act is authorized by a person. The only amnesty we can offer the programmer is that they are speaking an impossible language—one that is alien because it is unambiguous—and therefore should be treated like someone who doesn’t fully know what they are saying.