Microsoft Office is composed of 40 million lines of code. Mac OS X clocks in at 85 million lines. A high-end car reaches one hundred million. The sum of Googleʼs internet services amounts to two billion lines. These texts, which are written almost exclusively in English words, now represent a significant portion of todayʼs written culture. Yet code, which is quickly becoming the largest body of text produced by our species, is going largely unexamined. It is a constant, inescapable presence in our lives, but for most of us it remains carefully hidden.

Literacy

A central reason why this literature remains unnoticed is because, on the face of it, code does not seem to be of any use when considered in its written form. Engendered by engineers, the general thought is that digital computing is a process seen as valuable only if it is executed. A regular algorithmic operation is considered to hold worth only if it leads to an output, and it is that output which forms the center of any discussion about its worth. If code does not run, the common thinking holds, it is useless and unworthy of consideration.

This article imagines the opposite. In the wake of the ‘computational thinking’ and ‘code literacy’ craze that has sprung up in the United States and is slowly spreading to other countries, Iʼd like to suggest an alternative in which code is treated first of all as a textual endeavor, and analyzed with tools usually reserved for prose and poetry. To speculate on the future benefits of such a perspective, Iʼll start with a brief comparative look at the histories of both programming and writing.

Code History

Throughout its early era, programming concerned itself strictly with numbers. Itʼs been a long time since those who write software have abandoned numbers for the sake of words—more specifically, English words. And while any historical account of software development is of course deeply tied to the political economy surrounding it, the importance of this particular paradigm shift—of the very mode of description—is often overlooked.

There are two important moments in that shift. The first is the appearance of assembly languages. These languages were the first that allowed us to type letters that were not referring to mathematics, but to computer operations. From the days of Babbage through Turing and until roughly 1950, computer code consisted exclusively of numbers. But by the beginning of the 1960s, assembly languages allowed whole English words to be typed into and understood by the computer. Simple words such as move, add, and put marked the start of a pivotal journey, from an interface limited to bare-boned, ‘cold’ machine logic towards one that more fully attempted to reflect the human.

The second key turning point in this evolution was the switch from functional programming to object-oriented programming—two distinct schools of thought on how a language should work. Functional languages remained tied primarily to mathematics: expecting an input, returning an output. Alternatively, object-oriented languages introduced the notion of an object: an aggregate of data arbitrarily written up by a programmer to represent a particular type of thing. If youʼre building a database of user profiles for an ad agency, itʼs going to be hard to do so in functional programming. Yet object-oriented language is based on the use of words to describe data; in this case, the database would conceivably be constructed of words such as customer, age, financial situation, and taste.

While the objects of any programming language are strictly tied to mathematics, the ones we started to write around the 1980s had more to do with us—our lives and our world—and more to do with quality than quantity. Thus, writing commands for that purpose relied even more on a creative act than ever before, by molding the innumerable into numbers with more and more skill.

But of course, regardless of this difference, any written code still functions as executable. Lawrence Lessig’s work on code as a legal apparatus provides us here with an interesting perspective. Code acts as law, determining what can and cannot be done, and one can find in the intricacies and rigorousness of those machine-influenced languages an odd similarity to legal lingo.

This brief historical outline displays the progression of computer code from the numerical to the textual, legal, and political. It is no coincidence that this path is remarkably parallel to the one seen in the development of a much more ancient technology—that of the writing of natural language.

Natural Language

While language’s status, origin, and acquisition is widely debated, its writing is very much considered a technology—something devised to solve a problem. The primary problem was memory.

Regardless of their independent places of origin—Mesopotamia, Central America, or Southeast Asia being the most ancient—all writing systems are informed at their very foundation by the need to solve the problem of memory in a commercial setting. This need is resolved by the use of two qualifiers: a quantity and an object (three sheep, four sacks). In Mesopotamia’s case, cuneiform writing emerged as an offshoot of the second part of the problem: that of quality. What is it that you have?

The solution to this problem allowed for a new ability to tell stories, and led to the written ability to recount religious texts, myths, and imperial edicts. Codifying common stories made it easier to collectively apprehend the world in all of its complexity, from death to seasons to celestial bodies. While there are ancient records of that new technology being used for private communication, most of the preserved texts concerned themselves with ruling, either from a legal, religious, or cosmogonical standpoint. The written word came to express the way its users considered the world to behave, and opened new paths for expressing the poetic and the prosaic.

If our natural writing evolved from meeting a need to count, to a need to dictate, to a need for creative expression, is it possible that our mechanical writing will follow the same trajectory? Is it possible that writing code, currently being used to count and to dictate, could be developed towards serving an expressive, poetic impulse? And, if so, what are the specific constraints that would enable us to explore the new possibilities this type of text allows, further down a route that has not yet been traced?

Poetic Coding

Christopher Strachey was one of the first writers to reach into the expressive realm of computer code. In 1952, he wrote a program that generated love letters. Using techniques derived from the field of mathematics, an abridged version of his work would read along the lines of:

 var adj = 
  ['bright', 'delicate', 'beautiful', 'unique']; 
 var verb = 
  ['desire', 'adore', 'miss', 'obsess']; 
 var adv = 
  ['truly', 'deeply', 'constantly', 'subtly', 'eagerly']; 
 var noun = 
  ['light', 'life', 'fire', 'loins', 'sin', 'soul'];
     
 var letter = 'My ' 
 + adj[Math.floor(Math.random()*adj.length)] + ' '
 + noun[Math.floor(Math.random()*noun.length)] + ' '
 + adv[Math.floor(Math.random()*adv.length)] + ' '
 + verb[Math.floor(Math.random()*verb.length)] 
 + ' your '
 + adj[Math.floor(Math.random()*adj.length)] + ' '
 + noun[Math.floor(Math.random()*noun.length)] 
 + '.\n'
 + 'You are my ' 
 + adj[Math.floor(Math.random()*adj.length)] + ' '
 + noun[Math.floor(Math.random()*noun.length)] 
 + ',\n' 
 + 'Yours '
 + adv[Math.floor(Math.random()*adv.length)];

 

Executing such code would result in passages like:

 

My bright light truly desires your delicate fire.
You are my beautiful fire, Yours deeply

Or:

My unique loins constantly miss your beautiful soul.
You are my delicate sin, Yours eagerly

 

While none of these generated love letters are anywhere near as bad as the worst ones written by a human, it is safe to assume Strachey, working with his sister Barbara and Alan Turing, was aware of the mediocrity of the output when assessed by traditional tools. But this is where output ceases to matter.

When literary critics review a text, they consider it as the direct, unmediated result of an act of writing. However, in this example, the text is written twice, in two very different ways. The first is the code, designed to be legible to the computer, and the second is the result of the computer’s execution of that code, aimed at the human reader. The latter output was actively written by the computer. But when assessing such work, one should keep in mind the fact that the computer was enacting an underlying original text, similar to how an actor enacts the text of a play, or the executive branch of a democratic government enacts written law.

These comparisons are useful because we all accept that the production of a play and its source text are not one and the same. Likewise, the interpretation and enforcement of a law and the source text of that law are not one and the same. In a similar manner, the execution of a computer program and its source text are different things. Thus, if one chooses to read computer-generated text as a text authored by a human, which of course it is, it is crucial to view it through such a prism of enactment, and to avoid overlooking the source text—the original code.

Looking at the code of Strachey’s program rather than the the lines of text ‘enacted’ by the computer allows us a much clearer perspective on the idea behind the action. When we look at the source code, it becomes clear that Strachey’s program is, beyond its whimsical experimentality, an attempt at grasping the ideal form and ideal structure of a love letter without falling into the more defined frame of thought inherent in natural English. Is it possible to consider the quality of a love letter by examining its construction of adjectives, nouns, and adverbs? Strachey does not offer a clear response, but that question can only be asked when one reads the source code itself. That is because the semantic structures that allow such questioning are those of the variable name, of the array data structure, of the generation of random numbers and concatenating strings of text.

When considering the ubiquity of computer languages in our lives, one could see them as the new figures of speech of our times. And while it might be possible to beautifully express these same questions in natural language, computer code, because of its ability to be validated by a mathematical machine, allows us a new type of thoroughness, or creative constraint, in our exploration of the answers.

Affordances of Static Code

“Rose is a rose is a rose is a rose”

This passage, from the poem “Sacred Emily,” is one of the better-known works penned by Gertrude Stein, a writer who happened to be working at the dawn of the computer age. The assertion encapsulates Stein’s investigation of the logic at the heart of language.

It is worth noting that Stein’s passage is not entirely tautological: the context of the poem makes it clear that the first mention of Rose refers to a person bearing that name, and it is the following ones—those describing a quality of Rose—that point towards a looping semiotic logic system.

This same point may be helpful when considering a passage by Bertrand Russell, a logician and philosopher (and Stein’s contemporary), who wrote in 1905 that “The usefulness of identity is explained by [this] theory. No one outside of a logic-book ever wishes to say ‘x is x’[.]”

What might we find if we transpose these observations about the the essence of being and similarity into lines that form a computer-executable program?

Here is what one could consider a source text for that poem, written in Python.

     a_rose = "a rose"
     def it():
       return "a rose is "
     while a_rose is a_rose:
       print it(),

Stein’s repetition of a phrase is based on the different meanings of words in English and the relationship of these words to their signified counterparts, and Russell’s perspective is focused on the ontological properties of a thing being described. Writing this poem in a computational language allows us to try to grasp a few different concepts: repetitive quantity, degrees of similarity, and surface naming.

Repetition

While Stein’s use of repetition directly reflects upon the eternal, it always stops at a given moment. A computer program, written in code, will never stop. On the second-to-last line of the code above, the word while is that which ‘brings the text to life,’ implying the requirement for a condition of temporal permanence to be fulfilled. In our case, we are requiring a_rose to be equivalent to a_rose. This syntax explicitly requires that statement to be true for anything else to happen. If a rose is not a rose, no discussion is possible, and nothing can happen. Only when that condition is satisfied, a rose will be a rose, will be a rose, ad infinitum.

Identity

Another way in which source code can be reached into for poetic expression is by providing degrees of similarity between thoughts and concepts. Programming lets us work with data types—those made-up words and concepts—and has a fundamentally different way of dealing with whole numbers, floating point numbers, images, text, etc. In our case, we decide to represent a_rose by a string of text and not, say, a number or an image. In this case, the data type becomes a stylistic choice. We could have described a_rose as such:

     a_rose = open('rose.pde')

in which rose.pde is another script along the lines of:

     int void = 200;
     float bloom = 0;
     int blossom = 20;

     void setup()
     {size(600,600,P3D);
     }
     void draw()
     {  translate(300,300);
     strokeWeight(3);
     rotateY(cos(bloom));
     stroke(229,0,54,20);
     rotateZ(sin(bloom));
     fill(1,150);
     box(void-bloom);
     bloom+=0.05;
     if (bloom>blossom) bloom=20;
     }

which, in turn, describes the visual representation of a rose.

Data types act as a way to contextualize the concept evoked in the source code. A rose could be a word, a series of geometric coordinates, or another program altogether. Choosing the nature (the type), on top of the content itself (the rose) gives us a more subtle expression of what a flower could be.

Naming

Another layer of literary interpretation lies in between the variable names. As one of the few things that are not strictly enforced by the computer’s parsing of the text, variable names are what link the computable truth to the imaginable realm in our human minds. In an exclusively functional paradigm, one is told to have as little discrepancy between variable names and what they do in their program. However, in that space of undefined-ness lies yet another possibility for the poetic. Naming our variable itself results in:

     while itself is itself:
     print it(),

We get further away from the necessity to specify what a rose is, and deeper into the ontological realm, doubling down on our critique of the need to discuss whether something might not be itself. Without having recourse to specifically algorithmic syntax, variable names are a way to frame the understanding of the reader of both the ideal world in which the code acts and the mind of the writer. On open-source code repositories such as GitHub, one can find countless examples of writers for whom functionality was just an afterthought:

     var love = {"love": "Emma"};

This verse, found in a single-line file called index.js, was presumably used to test a section of code in a project titled demoslocosagainm, written by a user going by the pen-name hartlink. Is it more obvious, more important, that hartlink is in love with Emma, or that his code compiles? If we consider source code as a form of poetic expression, then what is being said here is more than simply an object declaration.

Conclusion

When we examine code in a manner closer to how we look at other writing, it becomes all the more apparent that features unique to this new mode of textual practice offer us unexplored methods of creative expression. A closer textual analysis of the source code creates avenues for new concepts, ideas, and beauty into our lives. While the output, or enactment of the source code, is central to any analysis of its value, we would be remiss to ignore the creative richness of its inner syntax. We are all users of code. We rely on it heavily. But developing ourselves into proficient readers of code could result in a shift in what code is served to us, and what that code does. An audience able to appreciate the products of both a functional programmer and a more creatively minded writer of code may well encourage coders to take advantage of the full range of creative output of this powerful mode of writing. Framing code—the basis for our current numbers-based, automated society—as an essentially poetic, aesthetic, and non-functional activity, could free it, and by extension, us, from the constant necessity to just work.