Blurred Lines: Literary perspectives on programming languages
With thanks to Nishant "@Rainypixels" Kothary, for filling in the gaps in my knowledge of programming languages and being an inspiring and insighful writing partner. This post originally appeared on Coding the Humanities.
I remember the day when I drew that first line on the screen of my computer using a command something like < line (x,y) >. I clicked "run" and indeed a line appeared. I had interacted with a machine that I'd formerly though of as both an enabled typewriter and a black box at the same time. I learned that my computer and I were capable of much more than text processing.
When I clicked run that day, something clicked within me too: I realised that programming and markup languages are just another type of language, only slightly different from those I'd been using my entire life. Treating programming languages as languages made them accessible to me. Yet, computer languages seemed much more able to eliminate ambiguity and appeared to be always performative.
The Story World of Programming Languages
Performatives, and its counterpart constatives, is a distinction made by John Austin in his 1962 work How to Do Things with Words. Constatives, Austin argues, are locutions (utterances) that say something about a state of affairs and can be either true or false. Performatives are locutions that accomplish something.
Of interest here specifically is a certain type of performatives: the explicit performative. The explicit performative is an act of speech (the overarching theory of performatives, constatives, locutions, and so on is called speech-act theory) that brings about a change in the state of reality. For example the sentence "I hereby pronounce you husband and wife." It needs to be pronounced by a certain institution and under certain conditions. Yet, if the context is right, a set of words changes reality. Methods–a programming procedure that accesses an object in object oriented programming languages–can utter the programming equivalent of "I hereby pronounce you to …" and change the state or function of the object altogether.
A closer look turns out that not every locution in programming languages is a performative. Booleans–formulas that are return either a true or false–are a great example of a constative (a locution that says something about a state of affairs and can be either true or false). The story world of programming languages turns out to be as much a linguistic treasure as literature and human language are.
The Humanness of Speech
In literary criticism, ever since William Epson published his Seven Types of Ambiguity in 1930, ambiguity is considered a poetic device. If used properly, ambiguity adds to the complexity of the text as well as the experience of the reader. Poetry and literature turn ambiguity into a sign of quality rather than an flaw, as it was and is still often regarded in human communication.
In programming languages, as in human language, ambiguity appears as something that should be avoided–a typo or simply omitting a semi-colon at the end of a sentence quickly results in an error message. It seems that if you want a software program to run properly, everything to the tiniest detail has to be in control. However, second look at programming languages reveals that ambiguity is inherent in programming languages as in human language. While the so-called diamond problem, causes programmers to seek ways to solve or avoid its ambiguity, game programmers are utterly comfortable with evoking spaces where ambiguity runs rampant.
Where computer programs become more and more complex and try to build increasingly complex forms of artificial intelligence, ambiguity seems to be more and more a prerequisite rather than an inconvenience. Human communication, despite how much we’d want it to, is never free of ambiguity. As literature has taught us, this is its beauty rather than fault. Subsequently, for a program to approach humanness as closely as possible, it has to embrace ambiguity and embrace its possibilities.
To a Shared Language
Allowing for ambiguity, however, entails opening up your artificial universe for unexpectedness, uncertainty and the potential of failure. Or as Nishant writes, this act diminishes the amount of control we can exert over these worlds:
A software program is really a rudimentary representation of reality with many axes of complexity reduced or entirely collapsed. The ability of programming languages to cut through ambiguity is actually a symptom of our own rudimentary understanding of the universe. We think that the ability of programming languages to eliminate ambiguity is a desirable feature (rather than a bug) because as humans we need to tell ourselves that we have some control of our environment.
Yet, the simple and deterministic programming culture of today is being replaced by more organic systems. Newer programming languages more closely resemble the way in which natural language works. The more natural the programs running our machines become, the less artificial they’ll feel. And the more room programming languages bear for ambiguity and complexity, the more they’re and our vocabulary to represent reality increases.
At first, human interaction had to be stripped down to its bare essentials in order for artificial intelligence and computer science to enact humanity in machines. Yet, today we’ve mastered the essentials and can add the complexities to it that make it human. We are ready to step away from software programs as the ideal and controlled versions of reality to machines that allow for complexity and the inevitability of uncertainty. The lines are blurred already. We should get ready for them to disappear.