![\"\"](\"https:\/\/itp.nyu.edu\/adjacent\/issue-1\/wp-content\/uploads\/sites\/6\/2017\/08\/yt.png\")
<\/p>\n<\/p>\n
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\u02bcs internet services amounts to two billion lines.\u00a0<\/span>These texts, which are written almost exclusively in English words, now represent a significant portion of today\u02bcs written culture. <\/span>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.<\/span><\/p>\n 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. <\/span>Engendered by engineers, the general thought is that digital computing is a process<\/span> seen as valuable only if it is <\/span>executed<\/span><\/i>. A regular algorithmic operation is considered to hold worth only if it leads to an <\/span>output<\/span><\/i>, 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.<\/span><\/p>\n This article imagines the opposite. In the wake of the \u2018computational thinking\u2019 and \u2018code literacy\u2019 craze that has sprung up in the United States and is slowly spreading to other countries, I\u02bcd 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\u02bcll start with a brief comparative look at the histories of both programming and writing.<\/span><\/p>\n Throughout its early era, programming concerned itself strictly with numbers. It\u02bcs been a long time since those who write software have abandoned numbers for the sake of words\u2014more 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\u2014of the very mode of description\u2014is often overlooked.<\/span><\/p>\n 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 <\/span>move<\/span><\/i>, <\/span>add<\/span><\/i>, and <\/span>put<\/span><\/i> marked the start of a pivotal journey, from an interface limited to bare-boned, \u2018cold\u2019 machine logic towards one that more fully attempted to reflect the human. <\/span><\/p>\n The second key turning point in this evolution was the switch from functional programming to object-oriented programming\u2014two 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 <\/span>object<\/span><\/i>: an aggregate of data arbitrarily written up by a programmer to represent a particular type of thing. If you\u02bcre building a database of user profiles for an ad agency, it\u02bcs 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 <\/span>customer<\/span><\/i>, <\/span>age<\/span><\/i>, <\/span>financial<\/span><\/i> situation<\/span><\/i>, and <\/span>taste<\/span><\/i>.<\/span><\/p>\n 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 <\/span>us<\/span><\/i>\u2014our lives and our world\u2014and more to do with <\/span>quality<\/span><\/i> than quantity. Thus, writing commands for that purpose relied even more on a creative act than ever before,<\/span> by molding the innumerable into numbers with more and more skill.<\/span><\/p>\n But of course, regardless of this difference, any written code still functions as executable. Lawrence Lessig’s work on code as a legal apparatus<\/span> 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.<\/span><\/p>\n 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\u2014that of the writing of natural language.<\/span><\/p>\n While language’s status, origin, and acquisition is widely debated, its writing is very much considered a technology\u2014something devised to solve a problem. The primary problem was memory.<\/span><\/p>\n Regardless of their independent places of origin\u2014Mesopotamia, Central America, or Southeast Asia being the most ancient\u2014all 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?<\/span><\/p>\n 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.<\/span><\/p>\n 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?<\/span><\/p>\n 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:<\/span><\/p>\n <\/p>\n Executing such code would result in passages like:<\/span><\/p>\n <\/p>\n My bright light truly desires your delicate fire. Or:<\/span><\/p>\n My unique loins constantly miss your beautiful soul. <\/p>\n 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.<\/span><\/p>\n When literary critics review a text, they consider it as the direct, unmediated result of an act of writing. However, in this example, <\/span>the text is written twice<\/span><\/i>, 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\u2019s 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 <\/span>enacting <\/span><\/i>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. <\/span><\/p>\n 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 <\/span>as<\/span> a text authored by a human, <\/span><\/i>which of course it is, it is crucial to view it through such a prism of enactment, and to avoid overlooking the source text\u2014the original code.<\/span><\/p>\n Looking at the code of Strachey\u2019s program rather than the the lines of text \u2018enacted\u2019 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\u2019s 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. <\/span><\/p>\n 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.<\/span><\/p>\n \u201cRose is a rose is a rose is a rose” <\/span><\/em><\/p>\n This passage, from the poem “<\/span>Sacred Emily<\/span>,” 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\u2019s investigation of the logic at the heart of language.<\/span><\/p>\n It is worth noting that Stein\u2019s passage is not entirely tautological: the context of the poem makes it clear that the first mention of <\/span>Rose<\/span><\/i> refers to a person bearing that name, and it is the following ones\u2014those describing a quality of Rose\u2014that point towards a looping semiotic logic system. <\/span><\/p>\n This same point may be helpful when considering a passage by Bertrand Russell, a logician and philosopher (and Stein\u2019s 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 \u2018x is x\u2019[.]” <\/span><\/p>\n 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? <\/span><\/p>\n Here is what one could consider a source text for that poem, written in Python.<\/span><\/p>\n 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.<\/span><\/p>\n 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 <\/span>while<\/span><\/i> is that which \u2018brings the text to life,\u2019 implying the requirement for a condition of temporal permanence to be fulfilled. In our case, we are requiring <\/span>a_rose<\/span><\/i> to be equivalent to <\/span>a_rose<\/span><\/i>. This syntax explicitly requires that statement to be true for anything else to happen. If a rose <\/span>is not<\/span><\/i> 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. <\/span><\/p>\n 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\u2014those made-up words and concepts\u2014and has a fundamentally different way of dealing with whole numbers, floating point numbers, images, text, etc. In our case, we decide to represent <\/span>a_rose<\/span><\/i> 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 <\/span>a_rose<\/span><\/i> as such:<\/span><\/p>\n in which rose.pde<\/i> is another script along the lines of:<\/p>\n which, in turn, describes the visual representation of a rose.<\/span><\/p>\n 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.<\/span><\/p>\n Another layer of literary interpretation lies <\/span>in between<\/span><\/i> 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:<\/span><\/p>\n 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:<\/span><\/p>\n 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.<\/span><\/p>\n 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 <\/span>readers<\/span><\/i> 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 <\/span>writer<\/span><\/i> of code may well encourage coders to take advantage of the full range of creative output of this powerful mode of writing. Framing code\u2014the basis for our current numbers-based, automated society\u2014as an essentially poetic, aesthetic, and non-functional activity, could free it, and by extension, us, from the constant necessity to just <\/span>work<\/span><\/i>.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" Written language evolved from purely practical functional uses into an expressive medium. Is there a similar future for code?<\/p>\n","protected":false},"author":1,"featured_media":1254,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-112","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-issue-1"],"_links":{"self":[{"href":"https:\/\/itp.nyu.edu\/adjacent\/wp-json\/wp\/v2\/posts\/112"}],"collection":[{"href":"https:\/\/itp.nyu.edu\/adjacent\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/itp.nyu.edu\/adjacent\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/itp.nyu.edu\/adjacent\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/itp.nyu.edu\/adjacent\/wp-json\/wp\/v2\/comments?post=112"}],"version-history":[{"count":0,"href":"https:\/\/itp.nyu.edu\/adjacent\/wp-json\/wp\/v2\/posts\/112\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/itp.nyu.edu\/adjacent\/wp-json\/wp\/v2\/media\/1254"}],"wp:attachment":[{"href":"https:\/\/itp.nyu.edu\/adjacent\/wp-json\/wp\/v2\/media?parent=112"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/itp.nyu.edu\/adjacent\/wp-json\/wp\/v2\/categories?post=112"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/itp.nyu.edu\/adjacent\/wp-json\/wp\/v2\/tags?post=112"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Literacy<\/h1>\n
Code History<\/h1>\n
Natural Language<\/h1>\n
![\"\"](\"https:\/\/itp.nyu.edu\/adjacent\/issue-1\/wp-content\/uploads\/sites\/6\/2017\/08\/face-07empt.png\")
<\/h1>\nPoetic Coding<\/h1>\n
var adj = \n ['bright', 'delicate', 'beautiful', 'unique']; <\/span>\n var verb = \n ['desire', 'adore', 'miss', 'obsess']; <\/span>\n var adv = \n ['truly', 'deeply', 'constantly', 'subtly', 'eagerly']; <\/span>\n var noun = \n ['light', 'life', 'fire', 'loins', 'sin', 'soul'];<\/span>\n \n var letter = 'My ' \n + adj[Math.floor(Math.random()*adj.length)] + ' '\n + noun[Math.floor(Math.random()*noun.length)] + ' '\n + adv[Math.floor(Math.random()*adv.length)] + ' '\n + verb[Math.floor(Math.random()*verb.length)] \n + ' your '\n + adj[Math.floor(Math.random()*adj.length)] + ' '\n + noun[Math.floor(Math.random()*noun.length)] \n + '.\\n'\n + 'You are my ' \n + adj[Math.floor(Math.random()*adj.length)] + ' '\n + noun[Math.floor(Math.random()*noun.length)] \n + ',\\n' \n + 'Yours '\n + adv[Math.floor(Math.random()*adv.length)];<\/span><\/pre>\n
\n<\/span><\/i>You are my beautiful fire, Yours deeply<\/span><\/i><\/p>\n
\n<\/span><\/i>You are my delicate sin, Yours eagerly<\/span><\/i><\/p>\n![\"\"](\"https:\/\/itp.nyu.edu\/adjacent\/issue-1\/wp-content\/uploads\/sites\/6\/2017\/08\/blacksEmpt.png\")
<\/h1>\nAffordances of Static Code<\/h1>\n
a_rose = \"a rose\"<\/span>\n def it():<\/span>\n return \"a rose is \"<\/span>\n while a_rose is a_rose:<\/span>\n print it(),\n\n<\/span><\/pre>\n![\"\"](\"https:\/\/itp.nyu.edu\/adjacent\/issue-1\/wp-content\/uploads\/sites\/6\/2017\/08\/RoseProgramShort.gif\")
<\/p>\nRepetition<\/h1>\n
Identity<\/h1>\n
a_rose = open('rose.pde')\n<\/span><\/pre>\n int void = 200;\n float bloom = 0;\n int blossom = 20;\n<\/span>\n void setup()\n {<\/span>size(600,600,P3D);\n }\n<\/span> void draw()\n {<\/span> translate(300,300);\n strokeWeight(3);\n rotateY(cos(bloom));\n stroke(229,0,54,20);\n rotateZ(sin(bloom));\n fill(1,150);\n box(void-bloom);\n bloom+=0.05;\n if (bloom>blossom) bloom=20;\n }\n\n<\/span><\/pre>\nNaming<\/h1>\n
while itself is itself:<\/span>\n print it(),\n\n<\/span><\/pre>\n var love = {\"love\": \"Emma\"};\n\n<\/span><\/pre>\n![\"\"](\"https:\/\/itp.nyu.edu\/adjacent\/issue-1\/wp-content\/uploads\/sites\/6\/2017\/08\/yellow-06.png\")
<\/p>\nConclusion<\/h1>\n