Field Report for Critical Code Studies, 2014


Field Report for Critical Code Studies, 2014
Over the past seven years since the publication of the manifesto on Critical Code Studies (CCS), ¹ the early explorers have established that examining code using humanities-style interpretive methodologies is a valuable part of the analysis of software and programming culture and have shown the first signs of how CCS might influence the writing of code, at least among artists. Situated within an array of emerging approaches, such as software studies, platform studies, media archaeology, and media forensics, Critical Code Studies works to develop methodologies for techno-cultural analysis through the exploration of source code, programming languages, the culture of codes, and algorithms as they are rendered operational in particular instances. In many ways, CCS takes for its milieu the code layer of Software Studies, especially as initiated in Software Studies: a Lexicon². Rather than examining source code to the exclusion of these other aspects of technology (i.e., the platforms, network, or interoperating software), CCS emphasizes the code layer in response to a lack of critical methodologies and vocabulary for exploring code through this cultural lens. As more of these methodologies develop, they can be used in conjunction with other approaches to analyze digital objects and the broader technoculture. This essay surveys some early developments in this nascent field.

With at least one book-length manuscript presenting its work as CCS,³ conferences and conference presentations, a blossoming bibliography, and even a lab focusing on CCS, the subfield has benefited from a wide variety of venues. In this article, I will attempt to review a selection from the recent work in CCS with particular emphasis on developments connected to the three Critical Code Studies Working groups (2010, 2012, 2014). Rather than a comprehensive survey, this article offers an overview of specific developments that have emerged through my interactions with a particular community of scholars in this area, and I write from the perspective of an investigator who is actively working to promote that field. Because this group has been in direct discussion with one another in a structured environment of online forums and conferences, I will present this evolution as a chronological progression, though I make no claims that the work of interpretation follows a developmental arc of scientific progress. Rather the practice of interpretating code is evolving, and there is still much exploration to be done.

During these very early years, Critical Code Studies has been wrestling with a number of preliminary questions and objections. Could code readers analyze, for example, only the comments inside the code? Can it only speak to code used in artistic projects, such as Perl Poetry or codework, projects that frame themselves as literary objects? Is the study of code limited to natural language elements in high-level programming languages or programmer-assigned, arbitrary variable names? Is CCS restricted to imperative languages? Is CCS constrained to human-generated code or could it also interpret code produced through programming software? In other words, there was a sense that for code to readable by cultural critics it would have to be written explicitly with an interpreting audience in mind. If such were the case, CCS would be limited to the realm of digital aesthetics. This survey reviews explorations that go far beyond code written for artistic ends, responding to the challenge of the original call to action in electronic book review to look beyond codework.

However, Critical Code Studies names scholarly practices which began long before that essay. CCS takes up the work initiated with techno-cultural critics Florian Cramer and Adrian Mackenzie, as well as code poets, such as John Cayley, Mez, and Alan Sondheim. It continues discussions of the nature of code that arose from computer science, questioning: What is code? How is it distinct from other sign systems? Can linguistic semiotics be applied to the study of code? To what degree is code performative? To these it added: What does semiotic interpretation mean in the context of code? CCS then sought to take these more abstract discussions and apply them to specific encoded objects. Despite much discussion and analysis of digital cultural objects, there was little precedent for such endeavors and resistance from scholars in both the realms of cultural criticism and code production.

Over the next few pages, I will review the developments of CCS in a roughly chronological manner. As one deeply engaged in these developments, I will narrate this progress as a participant-observer. I will also emphasize the conversations that were explicitly tied to CCS, either because they took place in a CCS forum or because the scholars mentioned CCS. Rather than offer this as an objective survey, I present these snapshots of Critical Code Studies from the perspective of one heavily invested in the development of this field. That investment leads me to pay close attention to contributions that advance conversations I participated in, though no doubt leads me to emphasize work from my network of research collaborators moreso than that outside it. Therefore, consider this literature review a glimpse into developments from the point of view of one exploring one node of the network while actively nurturing this incipient subfield.

Softwhere Studies [2008]
In 2008, SoftWhere Studies, an event organized by Lev Manovich, Noah Wardrip-Fruin, and Jeremy Douglass at the Software Studies Lab at UC San Diego, gave CCS a major boost. It was there that the organizers announced the Software Studies book series with MIT Press and invited proposal for the kinds of investigations that would be suited. Among the wide array of presenters and interests, they had invited me to give a talk about Critical Code Studies. At that conference, over a year since the publication of the original essay, I expressed my dismay that more people had not begun their work in CCS. ⁴ As it stood, several presentations at the conference focused on reading code, including Michael Mateas’ paper entitled “Authoring and Expression” ⁵ and Jeremy Douglass’ paper “#include Genre.”⁶ The question I continued to return to was why, despite more scholars discussing code and software, did most of these papers and manuscripts spend so little time actually analyzing the code. While I had several theories, the answers, which became clearer during discussions at the conference, were that there were many other aspects of digital culture drawing their attention (platforms, systems, et cetera) and that scholars did not have enough tools and methods for applying humanities-style inquiry to computer source code. Nonetheless, by featuring CCS readings as part of the conference, the organizers were signaling the strong ties between Software Studies and CCS.

Annakournikova at DAC [2009]
If Critical Code Studies was going to develop, it would need case studies. CCS appeared next at the Digital Arts and Culture (DAC) conference in 2009, where I was examining an elaborate codework by artist Zach Blas called transCoder. This case study requires a bit more explanation than the subsequent ones because it was controversial both in its approach and in its sexual politics. transCoder is a what Blas calls an “anti-programming language,” a kind of conceptual pseudo-code that according to Blas challenges the heteronormativity of code.⁷ While a superficial reading of Blas’ claim seems to suggest a “sexism” of coding language, along the lines of Microsoft adding 0xB16B00B5 (or BIG BOOBS) to the Linux Kernel,⁸ Blas’ intervention queers code both more explicitly and implicitly. In his words,
Code can morph to endless choices of queer non-essentialism: from Boolean statements transferring to a multitude of states beyond and between true or false, loops fluctuating wildly and unpredictably, if / then logic dissolving into if / if / if / if ad infinitum, small comments between pieces of code becoming digital manifestos for queer empowerment, the “logic” of queer discourse undermining control operators, variables stripped of heterosexist terminologies, to coding structures resembling passages from Butler, Haraway, or Irigaray rather than C++ or Java.
For CCS, Blas’ queering of the foundational logic of programming (i.e., binary, if-then, loops) presents a most radical cultural critique of code. However, even after pouring over his libraries, I still wondered what was the heteronormativity of code. On the one hand, his functions explicitly address gender constructions, as in metametazoan, which “deletes all semantically identified language that is representative of gender binaries and sets everything in the program equal to itself.” On the other hand, the method qTime (), or queer time, “permits the executions of a program to run outside of conventional computational narratives.” Blas is attempting to create a language that operates in an imaginary alternative computational space, one beyond the straightness of Boolean logic. The codework complicates a conventional understanding of code and yet does so with flights away from it.

Though transCoder offered a conceptual exercise, the piece became more than pseudo-code when it was implemented to by Julie Levin Russo in a program: the Slash Goggles Algorithm,⁹ a fan-driven code-work tied to the popular television remake of Battlestar Galactica (BSG). Russo’s program, or (to be precise) algorithm, picks up on the sexual play and punning in Blas’ work by offering an process that enables bioCyclon entities, the cyborgs of (BSG, to see the alternate sexual (or slash) possibilities of any scene in that television program. That she conceives of the code for Cylons as written in transCoder adds even more subversive innuendo to a series that was already playing with sci-fi tropes of Turing-Tests, posthumanity, and interspecies relationships. By using Blas’ code, Russo extends his artwork to show how it might serve as the basis for programs the same as a conventional programming language would.

Still, since neither of these projects could execute on a computer, to critique them alone would be to remain in the realm of conceptual art. For Critical Code Studies to investigate programming culture it had to do more than merely attend artworks about code. It had to produce its own critiques of functional code. However, these codeworks pointed toward avenues of critique. To test Blas’ claim, therefore, I chose a piece of code that seemed to depend on heterosexuality if not also heteronormativity. To this end, I chose the annakournikova worm that appeared around the turn of the millennium. This code provided two interesting characteristics for CCS, namely, it was created using worm-generating software and its code was obfuscated. Thus, reading the code would challenge the notion that only “handmade” code could be interpreted and, for that matter, only handmade code that seemed human readable at first glance. The code also did not lend itself to a surface understanding of heteronormativity. It did not contain, for example, variables with names that spoke to sexuality and indeed, having been generated by a computer program, operated in a mostly conventional manner. To find the heteronormativity, I had to follow Blas’ challenge to the logic of code. What I found instead was a normalizing logic in the operations of the code. If normalizing forces spread through tacit acceptance and transmission of their socially constructed rules, this code too spread by capitalizing on vulnerabilities in its human and machine victims, as the victim opened (and hence accepted) the alleged salacious images of the tennis ingénue and as the program exploited the vulnerability in Microsoft Windows, transmitting itself in a manner analogous to the unseen communication of a cultural norm.

This highly metaphoric reading of code explores the underlying computer culture that facilitated the circulation of the worm, the vulnerabilities (in both machines and humans) that were exploited, to develop an understanding of the Internet and email at the turn of the millennium as a place for the under-the-table circulation of salacious materials, illustrating an aspect of the sexual norms that underlie that network of humans and machines. Discussing the code created the opportunity for critiquing these aspects of computer culture, which taught me that CCS does not need to take code as its ends but rather as an entry point for a technocultural critique, a notion that has informed my definition of the scope of CCS. While previously, I had expected the code discussions would draw critics further into the history and context of code, through this experience and through my collaboration on 10 PRINT (discussed later in this article), I began to see how discussing the code more often led outward to discussions of platform, systems, or more broadly, context and developments before, during, and after the code’s production and circulation. However, for CCS to be a success, its explorations would have to go beyond the insights of anyone interpretation or interpreter to increase the understanding of code and culture. That task would require the collaboration of scholars from a variety of disciplines with a wide range of expertise. Such a meeting happened at the first Critical Code Studies Working Group (CCSWG).

CCSWG [2010]
While that initial essay and presentations at these two digital culture symposiums (and at others, such as Digital Humanities, the Society for Literature Science and the Arts (SLSA), and the Electronic Literature Organization) demonstrated the ideas, the first major collective developments in CCS, at least under that name, were the result of a six-week online conference called the Critical Code Studies Working Group.¹⁰ The working group followed a weekly discussion format, featuring a series of prominent scholars and artists. With over 100 members, over 100 posts, and deeply engaged discussion threads, CCSWG helped the early scholars to examine the possibilities and potential pitfalls of this emerging field of study.
During the third week of the Working Group,¹¹ Dennis Jerz presented the FORTRAN code for William Crowthers’ ADVENT (or Adventure) against the backdrop of his essay “http://www.digitalhumanities.org/dhq/vol/001/2/000009/000009.htmlSomewhere Nearby is Colossal Cave.”¹² In his article, in addition to offering a detailed background on the program and exploration of the caves that were the inspiration for this game, Jerz recounts the tale of spelunking for the code. During this week, he offered participants a chance to annotate the code collectively. As far as we can tell, this experiment represents the first collaborative CCS reading of a body of code. Some of the commentary drew attention to aspects of the code, the modeling of light for example or the similarities between “SUBROUTINE YES(X,Y,Z,YEA)” and the magic word from the game XYZZY. However, the bulk of that week’s conversation involved a debate about whether reflecting on the nature of programming languages, something that computer science had been doing from the start, would take precedence over individual comments on meaning of the code.

In addition, creating an engaging meditation comparing coding to playing and instrument, in “Chainsaws are Tools, Algorithms are Thoughts,” Stephen Ramsay performed a “live” reading of live coding. ¹³ During this play-by-play, Ramsay demonstrates how a reading can evolve out of observing the skillfulness of a programmer, in this case, Andrew Sorensen, who is creating code before our eyes with the virtuoso of a musician. Sorensen, in this case, writes in Impromptu, his custom Scheme programming environment, creating software instruments and then playing them by modifying their parameters. What makes this example so important for CCS is the way in which Ramsay situates code not as something that is a static artifact, but something that can be artfully created in real time, the product of clever choices, revisions, extensions, reconsiderations. Moreover, his live “color commentary” performs an example of the thought process of deriving meaning from code. Throughout the live commentary, Ramsay asks, “What is Sorensen doing here?”, translating Sorensen’s code by explaining how he assumes it works. At the point of the recording, Ramsay has purposefully avoided studying the syntax of the language so his first response can be more raw. As the livecoding performance continues, Ramsay comments on the elegance of the code, relating Sorensen’s choices to conventional livecoding strategies. Eventually, a kind of thesis emerges, or leitmotif, as Ramsay frames Sorensen’s coding as creating a software instrument and then playing it by changing the parameters. This reading brings his video full circle to its opening comparison of livecoders to other performers on musical instruments. Ramsay’s video in this way offers a model of how CCS readings emerge from the initial grappling with the literal functionality of the code to a focus on aspects of programming with broader cultural echoes and implications.

In addition to co-organizing the working group, Jeremy Douglass has contributed a number of important interventions in the analysis of CCS. At Softwhere Studies he asked about the place of code libraries in CCS readings.¹⁴ At the first USC conference, he explored the long tradition of discussing comments.¹⁵ However, one of his most influential contributions occurred during CCSWG, when he exhorted the community to seek examples of code readings in the wild. Douglass’ call to action challenged the novelty of CCS by arguing the code was already being discussed in many contexts, including the news coverage around the Climategate scandal, trials about software patent issues, and many online forums for programmers to discuss snippets of code. In the extensive tradition of discussions about snippets of code, Douglass invited the members of CCSWG to post passages of code for group analysis, an invitation that lead to over 25 “code critique threads,” and, in turn, many of the specific code readings that grew out of the Working Group. Many of the threads focused on just a few lines of code, while other took up larger issues, such as Gregory Bringman’s reflection on whether version control could be counted as code. Languages included MOO, BASIC, FORTRAN, Javascript, Perl among others. For this first working group, each code excerpt was presented as a test for interpretation to explore it boundaries, expand its vocabularies, and enrich its practices through collaborative analysis.

Wendy Chun’s week in the CCSWG presented the opening chapter of her then in-progress book Programmed Visions. With extensive training in electrical engineering and the humanities, Chun had already established herself as a scholar skilled at exploring technology through continental philosophy. Chun’s opening chapter takes up the mythos of source code as magical originary text, which she calls “sourcery.” She writes, “To break free of this sourcery, we need to interrogate, rather than venerate or even accept, the grounding or logic of software.” Amidst the many intricate readings of this analysis, she critiques the tendency to fetishize the code and to assign it a kind of primacy that it does it warrant, since the source code is not even the executable code. Moreover, the movement from high level code to machine language does not approach some heart of the code but rather, she argues, the electronic impulses and storage spaces that cause the machine to function. Chun’s text serves as an important corrective to the tendency to perceive the pursuit of code as the quest for the essence of the software. However, she suggests that critics engage in a creative and critical operation, to “re-source,” which looks not to uncover the truth of the code but to produce new levels of meanings about it by reading it in the context of a broader technocultural history.

CCS @ USC 2010
The Critical Code Studies Working Group led to the first conference on CCS at the University of Southern California in the summer of 2010. At this conference, scholars gathered to present their code readings, which were later archived on video and in text in Vectors Journal under the Thought-Mesh system. Although several of the presentations developed material first raised in the Working Group, the majority tended to offer new readings. Tara McPherson offered her reading of the history of Unix drawing parallels with the cotemporaneous Civil Rights movement,¹⁶ in a paper that later appeared in Matthew Gold’s Debates in Digital Humanities.¹⁷ Rather than reading racial history in code, McPherson demonstrates how changing paradigms in computation emerged simultaneous with changing paradigms in the way race was constructed in the United States at this volatile moment. As she writes,
I’m interested in how certain aspects of modularity, fragmentation, etc., that are endemic to code and to digital media also structure the more covert forms of racism and racial representation that categorize post-Civil Rights discourse.   I am not so much arguing that the two are causally related, but, rather, that both represent a move toward fragmentary knowledges, knowledges increasingly prevalent in the second half of the 20th century.
Rather than focus on specific passages of code, McPherson analyzes the structure of Unix.   In that version of this talk, she examines how “the privileging of the discrete, the local, and the specific emerges again and again in discussions of UNIX’s origins and design philosophies” (25). This she ties to “the emergence of covert racism and the rhetoric of colorblindness” (30). McPherson’s approach challenges the narrow analysis of the culture in which coding paradigms are developed by relating the development of these programming paradigms to the cultural logic of a broader and equally dynamic social history from which it has been more often segregated. By implication, the resultant readings of technoculture consequently seem to exist in a race-free (and gender-free and class free) clean room. Key to McPherson’s intervention is her ability to draw together Critical Code Studies with critical race theories, a move that expands the potential interventions of the “critical.”

Following a thread from the CCSWG, Federica Frabetti offered a reading of Fortran code that was incorrectly thought to have caused the failure of Nasa’s 1962 Mariner I probe:¹⁸
DO 10 I = 1.10
…
10 CONTINUE
This code would lead to an infinite loop. The corrected code would read, “Do 10 I = 1,10.” However, the code itself did not cause the crash of Mariner I, but instead what Frabetti calls “a combination of hardware and software failures.” What interests Frabetti is not that the code caused the catastrophic failure but that the urban myth grew up around that anxiety. She uses this example then of this infinite loop in this faulty code to theorize what she calls “the intrinsic fallibility of software that relies on linearization.” This linerarization, she argues, is what happens when the compiler processes the code, as she draws upon André Leroi-Gourhan concept of “the linearization of language.” For Frabetti, anxieties over code that is “perfectly” linearized, is a fear of “the prostheticity…of what we consider ‘the human’: never a master of its tools, always constituted through and with them.” Frabetti’s reading is significant because it reads code as a continuous with the development of the technology of written language.

10 PRINT [2010-2013]
One of the most high-profile projects to come out of the CCSWG was a book about a one-line program, 10 PRINT CHR$(205.5+RND(1)); : GOTO 10, known as “10 PRINT.”¹⁹ Begun as a code critique thread by Nick Montfort, 10 PRINT threw an encoded monkey wrench into the CCS project. First of all, it was so short (33 characters without spaces), there seemed to be hardly anything to discuss. Second, unlike other projects, this code possessed no variables or comments to offer signs of the program’s history or the programmer’s thoughts on the code. In fact, it does not have an author that we could discover, just its inclusion in the Commodore 64 User’s Manual. While a number of the early CCS readings dealt with more complex software with interesting operations, this program produced only what appeared to be a random maze pattern or, more precisely, a pattern formed from the pseudorandom alternation between two diagonal lines displayed in rows across a monitor. Even one of the most pregnant lines of inquiry, exploring its resemblance to mazes, was frustrated by the fact that the pattern was arguably not a maze at all, as José Carlos Silvestre reflected in his comments on the thread.

As discussion continued on that thread, it soon became obvious that at least some of the discussants found the little line of code to inspire quite a bit of creativity. John Bell, the first responder to the thread, considered the one-liner to be a kind of experiment, testing the affordances of an underlying system. He also mused that the program could be considered art, since “one aspect [of art] is often an attempt to provide insight into an invisible system by recontextualizing its rules and operations.” The question remained, however, how and what could we read? Bell proposed exploring the role of looping as well as the role of pseudorandomness. As we interrogated the role of the context of the code, its inclusion in a programming manual aimed at beginners, I began to wonder what other forms of instruction this code example resembled. This line of inquiry, eventually led me to place the code next to 19th Century books for young women about the craft of stitching, which included procedures of repeating alternating patterns, an argument I developed for an essay in Emerging Language Practices.²⁰ Montfort would build upon this provocative post, this stumbling block, a 10-authored single-voiced text exploring approaches to this one line of code.

The book, written not as a collection of essays, but one univocal text, takes all of the elements of this this seemingly straightforward code and uses them for the starting point of investigations. The book treats the output, the maze structure and all that it invokes, as well as the particular constraints of the C64 that make the program possible, for example, the C64’s PETSCII Code (a customized ASCII set) that included the diagonal lines to facilitate drawing. It also explores the place of the Commodore in the early “home computer” market. The advent of this more affordable computing device and its marketing to parents led to the creation of a generation of programmers who would be tantalized by the power of programming through a single repeated line. Exploring the relationship between the code, its platform, and the cultural moment, the book helped develop the ties between code studies, platform studies, and software studies. It demonstrated further how code can be an entry way into discussions of the larger networks of software, hardware, and, of course, humans.

Another notable reading to emerge out of the CCSWG code critiques was Mark Sample’s reading of Metropolis (the open-source version of SimCity). Sample had posted links to the open source version of the code, and invited readings that examined the relationship between the code and the simulation, again using the inside-outside approach, whereby the effects of the software are read against its processes. Sample focused particularly on the way crime was calculated as a function of the number of police stations in the vicinity and a passage of code that had been disabled, that created a disaster dangerously evocative of 9/11. By reading code that has been excised from the program and is now only a shadow in the comments, Sample emphasizes the ways code offers traces of decisions made in its evolution.

From A to Keywords of Markup [2010]
Although not explicitly connected to Critical Code Studies, 2010 also saw the publication of a collection of essays on markup, entitled From A to : Keywords of Markup.21 Edited by Bradley Dilger and Jeff Rice, this fine collection of essays offers a series of meditations organized around HTML and XML markup tags. Treating the tags, such as and to essay-long reflections, the contributors, which include Matthew K. Gold, Helen Burgess, and many others, delve into these markings that are hidden in plain sight, just a “view source” away from being exposed, and the language that many web authors see first. In the words of the editors, “markup is the culmination of cultural experience: narrative, assertion, secrecy, pedagogy, identity, rules, materialism, agency, the body, and other features” (xiv). While a markup language is not technically a programming language, it operates as a layer of code that is interpreted by the computer. The essays in this collection demonstrate the ways in which the tags of markup gathering meaning about them beyond mere formatting. A kind of everyday coding practice, markup occurs at the intersection of form and content. Interpreting markup presents a very accessible step for those who are studying objects on the Web who wish to make comments about the form of the content, yet might not be literate in any formal programming languages, so this collection provides a useful entre in CCS for those interested in reading web-based digital objects beyond the screenic effects and imagined processes of the software.

HASTAC Scholars Critical Code Studies Forum (URL) [2011]
On the 2011 HASTAC Scholars discussion forum, Max Feinstein and a group of graduate students joined CCS-affiliated faculty to discuss reading code. In many ways, this forum picked up where CCSWG left off, bringing it out of the walled garden into an open discussion board. The resulting forum had over 100,000 hits and over 100 comments. The group of coordinators included: Clarissa Lee (Duke), Jarah Moesch (Univ. Maryland), Jean Bauer (Univ. of Virginia), Peter Likarish (Univ. of Iowa), and Richard Mehlinger (UC Riverside). The conversations, which are still available online, raised fundamental questions about the role of CCS, complemented by a separate forum for code critiques. Several important ideas were raised during these discussions. I am going to focus on two of them.

The first arose from an interaction I was having with Evan Buswell, a professional programmer who is now pursuing a PhD. at UC Santa Cruz. During this exchange, I argued that despite the continued calls for CCS to focus on fundamental aspects of programming languages, there was something to be gained by interpreting the “arbitrary” elements of the code, such as variable names. Technically speaking, these elements are arbitrary because, within the constraints of any programming language, their choice does not significantly affect how they are processed by the computer. Call a function “divest” or call it “x92929s,” and the computer does not change the way it processes the information. By contrast, the difference between the keywords “public” and “private” in the declaration of Java methods is built into the language, and hence has special relevance within the semantics of Java. Responding to my provocation, Buswell warned that if CCS only dealt with the arbitrary, then digital humanities scholars dealing with code would be relegated to the decorative aspects of code, rather than the fundamental elements, and their contributions would be seriously devalued as the proper scientists went off to discuss important matters in the study. He wrote,
But when I hear about these arbitrary elements, I keep imagining this world twenty years in the future, where CCS is an established, successful practice….CCS is part of the Computer Science curriculum, a lot like a “critical thinking”-style composition course for code.  And CS teachers tell all their students that they’ll be working with programmers from India, from Israel, from Singapore, that understanding the politics of how you name your variables is important in our globalized world, and they’ll tell stories about a programmer some CCS person nailed in court, and they’ll recommend that in addition to their class dealing with the real and actual practice of computing, they should take this other class about how code appears to others.  CCS will have been wildly successful as a discipline, people will be forced to confront it, but all the while there will be an invisible line between CCS and CS, protecting the core from the periphery, insulating and separating from critique the power structure of code itself, and constructing a discourse of “good code” and “bad code” to go along with the discourse of “good business” and “bad business” that tends to dominate naive anti-capitalist critique.
Buswell’s vision of the CCS/CS divide was pivotal to discussions because it succinctly articulated what is at stake when humanists grab onto what might be the easiest aspects of code to comment on (namely the arbitrary). Such a choice, in Buswell’s view, would exacerbate the existing divide between the two academic worlds.

Another significant objection came from Matt Kirschenbaum, who expressed a concern that by focusing on the analysis of code snippets, CCS could potentially abstract code from its larger software constructs. This objection seemed to echo Chun’s concerns about fetishizing the source code, that to focus on code was to misrepresent it as the magical core. Kirschenbaum also expressed concerns about the tendency to move toward close reading in code. Extending his comments from a 2010 MLA panel on CCS, Kirschenbaum said, code “was not ‘close’–micro–so much as precisely *macro,* an actant (after Latour) that exists only amid the layers of formal materialities marking complete computational environments, von Neumann’s or otherwise. ” Responding to Friedrich Kittler’s dictum that “There is no Software,”²² Kirschenbaum wrote, “I  prefer to say that there is never *just* software, that software (and code) always exists within a human lifeworld that encompasses everything from those coffee-stained napkins to carpal tunnel braces to real estate prices in New Delhi. Not to mention the programmer, the coder, who has a body (Ellen Ullman’s non-fiction essays in Close to the Machine still hold up very well here).” A suggestion emerged that CCS could address this problem in part by reading code in the context of its versioning software, in other words, to read code in the context of the other files it required as well as the revision logs .
In response to this critique, I have begun a reading of the Transborder Immigrant Tool,²³ a java-based mobile phone application designed to sustain immigrants to the United States in their last mile of the journey by directing them to water and nurturing them with a highly pragmatic poetry. At the first CCS conference at USC, Electronic Disturbance Theatre member Brett Stalbaum released the code for TBT on Source Forge. While the code would not include all of the prior developmental logs, this new repository would track all further changes and developments in the software. As part of the NEH Vectors Summer Institute, I began a close reading of the code from this repository on their multimodal publishing software, ANVC Scalar.²⁴ Developers Erik Loyer and Craig Dietrich have given that platform, among many other features, the ability to import code directly from Source Forge, allowing even line-level annotations. As a result, the code files remain tied to their larger context within the code repository. Using this approach, critics can analyze smaller sections of code without separating them from the larger systems in which they operate. Such an approach also allows particular code readings to provide the fullest possible materials to inspire future readings, for, unlike a work of literature, the files from which a snippet is extracted is often not readily available to the readers of the critique. Even the examples of code readings here, other than 10 PRINT and Jerz’s reading of ADVENTURE, tend to quote the code as one would lines from a play or novel. However, since most scholars do not have at their disposal a library of code to draw upon, readers often have to take the critic’s word for the functionality of the code that has not been presented. These developments in Scalar were inspired by Dietrich’s proposal for a system he calls “Magic” which would enable complex explorations of code including multimedia annotations, split-screen comparisons of code passages, and non-linear traversal of the code.

The Philosophy of Software: Code and Mediation in the Digital Age [2011]
One of the most prolific contributors to the CCSWGs, David M. Berry has also contributed one of the most extensive manuscripts on reading code and code culture. The Philosophy of Software contains chapters on the epistemology and ontology of code, reading and writing code, running code, and the phenomenology of code. Written for a general audience, the book reads several code examples including the Microsoft Windows 2000 source code and obfuscated code competitions. In this text, Berry frames code as a super medium, as it “unified the fragmented mediums of the twentieth century (tv/film/radio/print) within the structure of code” (10). “Code,” Berry continues, “is not a medium that contains the other mediums, rather it is a medium that radically reshapes and transforms them into a new unitary form. The super medium acts as both a mediating and structuring frame that we must understand through its instantiation under particular physical constraints” (10). Rather than examining code qua code, Berry examines “the assemblage presented by the computational and the human” (10). This grounding for his book allows Berry to avoid the fetishization of code while still situating it as the site of connection between agents, whether human or machine.

CCSWG12 [2012]
In 2012, in the second Critical Code Studies Working Group, 85 scholars of diverse backgrounds convened online to discuss major topics related to code and to develop individual code critiques. This time, with the creation of the Humanities and Critical Code Studies Lab at USC, the two conferences, and the previous working group, there were already a group of scholars who had established their affiliation with CCS. As a result, this working group no longer had to debate the potential and pitfalls of CCS. Instead, it could delve into special issues. That second CCSWG focused on three topics: ethics, literacy, and play, with each theme led by a different group of scholars.²⁵

Week 1 Ethics
The discussion of Ethics was led by Evan Buswell, Scott Dexter, Craig Dietrich, and Elizabeth Losh, who asked what ethical issues were unique or uniquely structured in the context of code? Does code call for a kind of ethical evaluation distinct from those that involve humans and human-based systems? The thread began with a suggestion of starting nodes, including: writing and reading code and buggy code. The group asked where culpability lies when a catastrophic error is caused by one line of code, citing the case of the Therac-25, the radiation therapy machine on which the treatment of a variable caused it to expose patients to lethal doses of radiation. The group also raised the work of philosopher Roberto Esposito whose notion of gift and obligations offer a framework for discussing the ethics of free and open-source software development. It was clear even in the post that launched this discussion that the topic of could fill all the sessions of the entire working group, underscoring the importance of examining questions of ethics throughout CCS readings.

The discussions wove these various threads together. Warren Sack began to articulate a Foucaultian “care of self” or “technologies of the self,” wherein the computer is situated as an extension of the self, as a means of transforming themselves, moving toward perfection and wisdom. Jason Lipshin complicated the discussion by disrupting the image of the program as the execution of the programmer’s intention by framing the code as a collaboration between humans and machines often with unintended consequences. Evan Buswell similarly intervened to note that code has no meaning on its own. He writes, lines of code can “only acquire meaning through their interaction with compilers, machines, other code, the network, and humans.  As the code leaves its author, it takes seed elsewhere and acquires new meanings.  What defines code, maybe more than anything else, is our absolute insistence that in code all dissemination is to be recaptured, that meanings must not stray from the original.  This insistence always fails, eventually, if for no other reason than the mortality of our machines (far more mortal than we are, in my experience).”

Week 2 Literacy
2012 was called the CodeYear ,²⁶ and people from all walks of life were making resolutions to learn how to program. Even the Mayor of New York made the pledge. Following suit, one of the main topics for CCSWG12 was literacy. The chief question was how best to teach programming outside of computer science. While many universities have programming courses for non-majors, the questions were framed in the larger context of the developments of Digital Humanities scholars, large numbers of whom are eager to move beyond GUI-level engagement with software. It is tempting to speak about fluency with code as a literacy, analogous to reading natural language. However, over the past several years, scholars have been offering alternative models that more closely attend to the specific status of code. These alternative models begin with Jeanette Wing’s “computational thinking” and continue with Michael Mateas²⁷ and Ian Bogost’s²⁸ “procedural literacy” adapted from B. A. Sheil, Annette Vee’s portmanteau “proceduracy,”²⁹ and David M. Berry’s “iteracy,” which emphasizes the notion of “iteration” in the development of code ³⁰. This group’s discussion began to lay the groundwork for an understanding of competencies in algorithms distinct from fluency and comprehension of natural language. Also, the group noted the particular means of achieving that mastery in a cultural moment where “digital humanists” were beginning to feel an anxiety about and a desire to learn how to program. It was clear from discussions that a growing sense of the importance of knowing about code and how to program amongst humanists and other nonprofessional programmers would lead to a growth in the community of humanities scholars able to read code critically.

Week 3 Play
The “Play” week, coordinated by Stephanie Boluk, Jeremy Douglass, Patrick Lemieux, and Mark Sample, explored the intersection of code and video games, exploring several main threads. The first was the existence of coding in games, games that foregrounded the act of programming. Among other works, Sample offered the example of “The Naked Game,” a version of Pong in which the players can click on represented lines of code to erase them and witness the effect of stripping away the code. This notion of “programming as play” led to Boluk’s discussion of Chris Novello’s work. Through his “codebending,” “the stepchild of live coding and circuitbending,” Novello uses “Open Sound Control” to “treat systems themselves as playable objects.” In essence, Novello is using software to make other software playable objects in ways they were not intended.

The second main idea focused on what Stephanie Boluk and Patrick Lemieux called “strange IDEs” or games that seemed to foster programming activity. Their discussion of players building simulated computers in games such “Dwarf Fortress” raised the question “What is the difference between building…and coding.” In this portion of the Play thread, Boluk and Lemieux raise questions about what constitutes programming and whether Critical Code Studies would not have to also account for programming in environments that look nothing like code editors. ³¹

The 2nd Critical Code Studies working group continued the code critique threads amassing 27 such critiques from a tokenizer/lexer written in Haskell to the code for Jim Andrews’ artwork Webarteroids2. In this second stream of code critiques, the objects of study were even more wide-ranging than the first CCSWG. A cluster around works of electronic literature, examined the way the code spoke back to the piece, for example the code of Stuart Moulthrop’s Reagan Library. Others explored the legibility of code, as in Eric Rochester’s thread about the Haskell program that turns a stream of text into a set of tokens. Some of these code critiques raised questions essential to the project itself. Ben Allen presented an exploit described in Ken Thompson’s Turing Award Lecture “Reflection’s on Trusting Trust” which details what amounts to an undetectable hack, wherein the hacker writes functions that insert bugs into the source code of the system’s compiler itself. According to Allen, Thompson uses this compiler hack to introduce a notion of the unreliability of the code and to counter the assumption that the source code and the program are the same thing or that there is a simple deterministic relationship between what the code specifies and what it ultimately becomes.

Reading Project: A Collaborative Analysis of William Poundstone’s Bottomless Pit [2009-2014] ³²
In 2009, Jeremy Douglass, Jessica Pressman, and I began a project to close read William Poundstone’s work of electronic literature, Project for Tachistoscope [Bottomless Pit]. In this electronic narrative, Poundstone uses Flash to remediate a tachistoscope through which readers are given a fabulous story about an epically deep crater. Tachistoscopes are a class of technology that can display words and/or images rapidly before the viewer and have been used in everything from military training in Friend or Foe identification to teaching speed reading and testing psychological priming with subliminal words. Poundstone’s tachistoscope intersperses the words of the story about the pit, displayed one at a time, with a set of subliminal words, which appear too quickly to be consciously perceived. In the ensuing manuscript, I read the ActionScript code and Flash file in dialogue with Douglass and Pressman’s exploration of the visual and textual elements of the piece, to create mutually informing readings. In the code, I was not only able to locate the complete text of the piece but also variable names that changed the way we read the piece.

Reading Poundstone’s work as collectively made us realize the need for toll that would facilitate the collaborative exploration of many views of a digital object, including, of course, the source code. Specifically, that reading project led to a Collaborative Research Fellowship from the Association of Learned Councils for which we have been working to develop such a new platform. With the help of Craig Dietrich and Lucas Miller, Douglass, Pressman, and I have developed the prototype of ACLS Workbench (built on the Scalar platform) to facilitate these collaborative readings. The goal is to encourage scholars to share the code they are reading in order to invite the kinds of collaborative readings that happen naturally in works in which the texts are published on the surface of the piece, as in the case of a published play or book of poetry. Since the tool facilitates the annotation of code and weaving those annotations into larger arguments, Workbench offers a laboratory for exploring the ways that CCS can operate in a supportive capacity as part of a larger discussion of a work of digital art. This platform became one of the centerpieces of the third working group, CCSWG14.

Speaking Code [2013] ³³
One of the most significant contributions to the argument for humanities-style readings of code is executed in Geoff Cox and Alex McLean’s Speaking Code. In this book, Cox examines what he calls “computer code” through the lens of and as speech, including examining the role of the semiotic, the material, and the social in the circulation of code. Cox theorizes everything from the nature of code to the labor the produces code to poetic codework. Rather than offering detailed readings of specific works of code, Cox offers a duet or dialogue with source code written by Alex McLean, which complements his argument that code contains both a formal logic and an expressive function. As the book’s principal argument, Cox reads code as a kind of speech act, but when read as speech, code circulates as a channel of discourse which is by necessity social and potentially subversive. “Like speech,” writes Cox, “program code is active in the world and has a lived body, indeed is intimately connected to a social body” (100). Cox draws upon Gregory Bateson’s notion of “double description,” wherein the combination of two or more information sources provides information not present in either of them. In code work and other subversive expressions of code, Cox sees the potential for a “double coding” which can be expressive and yet nonfunctional. While Cox draws upon the speech acts, his readings are inflected with Butler’s notion that “speech is always in some ways out of control.” ³⁴ Cox also draws heavily on the work of Paolo Virno and Hannah Arendt. In this book the social speech of code is always a site of potential resistance, and in many ways the book is more a call-to-action for more disruptive coding speech acts, by offering specific destabilizing examples, than it is an analysis of code at large. Nonetheless, this book offers the clearest argument for code as a speech act and, with its second code voice, presents many snippets of code for future readings.

DHQ: Special Issue: The Literary [2013]
This special issue of Digital Humanties Quarterly (2013 7:1), edited by Lisa Swanstrom and Jessica Pressman, presents several essays that help develop the work of Critical Code Studies. The most formally innovative was composed by poet Stephanie Strickland and Nick Montfort. Their essay “cut to fit the tool-spun course” takes place in the comments of the code of their collaboration, the poetry generator “Sea and Spar Between,” which combines lines from Melville and Emily Dickinson in a veritable ocean of fragments. As when Brett Stalbaum announced the release of the code of the Transborder Immigrant Tool at the CCS conference, this essay in code offers another example of works of digital art created with an awareness of CCS and its code reading methods. Such works that produce code with a sense of an additional reader using CCS methods adds yet another level of complexity to the reading process, as this potential for a critical reading leads to a more measured signifying process. Another essay in this collection, “Criminal Code: Procedural Logic and Rhetorical Excess in Videogames” by Mark Sample builds on the code critique thread he began in a CCSWG, examining the code of the open source versions of SimCity in relation to the code from JFK: Reloaded. This piece shows how games studies can be extended with examinations of the code. Finally, my essay, “Code as Ritualized Poetry: The Tactics of the Transborder Immigrant Tool,” continues my reading of TBT from CCSWG12, reframing the code as one the one hand a kind of folklore as well as a form of conceptual poetry. These three essays demonstrate the influence of the work from the working groups on subsequent scholarly work in this area.

CCSWG14 [2014]

This year the themes for the Critical Code Studies Working Group have continued the themes of the previous two and notably returning to some of the controversial areas of cultural interpretation that caused the initial reactions against CCS. Nick Montfort lead the first week with a discussion of his vision for a new programming paradigm, which he calls “exploratory programming,” a paradigm epitomized by his own artistic practice developing poetry generators and other experiments. The second week took up a pursuit for “feminist code,” an incendiary proposal put forth by Arielle Schlesinger on the HASTAC Forum discussion boards that evoked scads of scorn and backlash. The responses included a 4chan parody called C+= (C Plus Equality) which was posted to and removed from several sites, including Google Code and GitHub.³⁵ To explore the possibility of a feminist programming language, Schlesinger offered the examples of mezangelle and a codework feminist code library by micha cardenas, designed to interoperate with Zach Blas’ transCoder, again returning CCS to the insights and interventions of code artists. The third week, led by Roopika Risam, Adeline Koh, and Amit Ray explored the potential for Post-Colonial readings of code and for code not based in English, using a proof-of-concept Arabic programming language (in the form of a JavaScript language interpreter) by Ramsey Nasser called alb (or “heart” in Arabic). Although these discussions explored post-structuralist identity theories, bringing the provocations of politics in to discussions of code, the scholarship of the past six years presented in this essay offered to these discussions ways to ground these conversations in a culture of code, rather than superimposing theories upon code. The working group continued to seek places where the theory illuminated code culture rather than excising the code from its context in order to make it perform the theory. That is a major step toward a CCS whose interactions with theory enrich rather than hijack pre-existing discussions of code within the world of computer science. The resulting discussions of the working group will be again published in electronic book review.
A final week launched a new platform for transmedial exploration of code, using ACLS Workbench for its principle platform for code reading. Workbench grew directly out of our collaborative reading of Project for Tachistoscope and was supported by a Collaborative Research Fellowship from the American Council of Learned Societies (ACLS). It was built by Lucas Miller, Craig Dietrich, and Erik Loyer upon the ANVC Scalar platform, drawing from some of the design principles of Border Codes. The project offers a platform for collaborating scholars to create collections of assets to promote multimedia readings of digital objects through, among other avenues, their source code. The goal of his project is to continue to pursue and promote more multimedia, anthropological approaches to understanding the code, through interviews, historical documents, documentation of the circulation of the code, and a deep understanding of the way the code functions and the machines with which it interoperates. This platform, therefore, picks up threads of 10 PRINT and other more extensive readings while heading the corrective warnings and guidance of those, such as Chun, Kirschenbaum, and Berry, who have underscored the limits and hazards of focusing on the code alone.

Future Directions
As an emerging subfield, Critical Code Studies is developing in ongoing conversations in journals, books, conferences, and across the Web. The Critical Code Studies and HaCCS Lab blogs continue to be forums for announcements of new discussions. The biannual working groups offer opportunities for scholars to gather and focus on code for a few weeks. The Twitter tag “critcode” labels a steady stream of links by those directly and indirectly affiliated with the study. For more formal references, the Zotero group archives a growing bibliography of titles related to Critical Code Studies. Also, consult David M. Berry’s Life in Code and Software (2012-present)³⁶ for an ever-evolving anthology of writing on these subjects.

As Critical Code Studies enters the second half of its first decade, it is clear that scholars are still only beginning to understand the many methods of analyzing and interpreting code. We have only begun to discover the vocabulary that is sufficient for discussing the analysis of code across disciplines, particularly straddling humanistic and scientific perspectives. We have begun, understandably, to talk about code by drawing analogies to semiotic systems that have already been analyzed. Eventually, we will develop frameworks that better speak to code’s unique qualities. However, once there are sufficient methods and theories for exploring the code layer, it is likely CCS will be absorbed into the broader field of digital studies. Until then, there remains a considerable amount of work to develop the frameworks for discussing code. These early developments offer a kind of proof of concept of the level of interest and the creativity that interdisciplinary communities of scholars bring to the exploration of culture through code.

 

References

Berry, David M. (David Michael). The Philosophy of Software: Code and Mediation in the Digital Age. Basingstoke, Hampshire ; New York: Palgrave Macmillan, 2011.
———. “Iteracy: Reading, Writing and Running Code.” Stunlaw: A Critical Review of Politics, Art and Technology, September 16, 2011. http://stunlaw.blogspot.com.es/2011/09/iteracy-reading-writing-and-running.html.
Blas, Zach. “Queer Technologies / transCoder / Sketches / About.” Queer Technologies / Transcoder / Sketches / About. Accessed September 8, 2010. http://users.design.ucla.edu/~zblas/thesis_website/transcoder/tc_about.html.
Bogost, Ian. “Procedural Literacy: Problem Solving in Programming, Systems and Play.” Telemedium 52 (Winter/Spring 2005): 32–36.
Boluk, Stephanie, and Patrick Lemieux. “Dwarven Epitaphs.” In Comparative Textual Media: Interplays Between Making and Critique. U of Minnesota Press, Forthcoming.
Chun, Wendy Hui Kyong. Programmed Visions: Software and Memory. The MIT Press, 2011.
“Code Year Draws 200,000 Aspiring Programmers.” CNNMoney. Accessed August 12, 2013. http://money.cnn.com/2012/01/06/technology/code_year/index.htm.
Cox, Geoff, and Alex McLean. Speaking Code: Coding as Aesthetic and Political Expression. Cambridge, Massachusetts: The MIT Press, 2013.
Dilger, Bradley, and Jeff Rice, eds. From A to A: Keywords of Markup. Univ Of Minnesota Press, 2010.
Douglass, Jeremy. “#include Genre.” Softwhere Studies. UC San Diego, 2008. http://www.youtube.com/watch?v=DixG0bwezns.
———. “Jeremy Douglass | Comments on Comments in Code.” In Critical Code Studies 2010 Conference Proceedings. University of Southern California: Vectors Thoughtmesh, 2010. http://thoughtmesh.net/publish/369.php.
Frabetti, Federica. “The Legend of Mariner I.” In Critical Code Studies 2010 Conference Proceedings. University of Southern California, 2010. http://thoughtmesh.net/publish/344.php.
Fuller, Matthew. Software Studies: A Lexicon. Illustrated edition. The MIT Press, 2008.
Jerz, Dennis G. “Critical Code Studies Conference – Week Three Discussion,” electronic book review, first person, May 25, 2011. http://www.electronicbookreview.com/thread/firstperson/colossal.
———. “Somewhere Nearby Is Colossal Cave: Examining Will Crowther’s Original Adventure in Code and in Kentucky.” DHQ: Digital Humanities Quarterly 1, no. 2 (2007). http://digitalhumanities.org/dhq/vol/001/2/000009.html#.
Kittler, Friedrich. “There Is No Software.” CTheory, October 18, 1995. http://www.ctheory.net/articles.aspx?id=74.
Marino, Mark C. “Code as Ritualized Poetry: The Tactics of the Transborder Immigrant Tool” 7, no. 1 (2013). http://digitalhumanities.org/dhq/vol/7/1/000157/000157.html.
———. “Critical Code Studies.” electronic book review, electropoetics, December 4, 2006. http://www.electronicbookreview.com/thread/electropoetics/codology.
———. “Critical Code Studies.” Softwhere Studies. UC San Diego, 2008. http://www.youtube.com/watch?v=5kB1dy0DAGQ.
———. “Critical Code Studies and the electronic book review: An Introduction.” first person, Accessed May 31, 2011. http://www.electronicbookreview.com/thread/firstperson/ningislanded.
———. “Emerging Language Practices : The ppg256 Perl Primer.” Emerging Language Practices, no. 1 (2010). http://epc.buffalo.edu/ezines/elp/issue-1/ppg256.php.
———. “Of Sex, Cylons, and Worms: A Critical Code Study of Heteronormativity.” Leonardo Electronic Almanac 17, no. 2 (April 30, 2012). http://www.leoalmanac.org/vol17-no2-of-sex-cylons-and-worms/?utm_source=rss&utm_medium=rss&utm_campaign=vol17-no2-of-sex-cylons-and-worms.
Mateas, Michael. “Authoring and Expression.” Softwhere Studies. UC San Diego, 2008. http://www.youtube.com/watch?v=XHdRBvHVdWE.
———. “Procedural Literacy: Educating the New Media Practitioner.” On the Horizon 13, no. 2 (January 6, 2005): 101–11. doi:10.1108/10748120510608133.
McMillan, Robert. “Microsoft Adds ‘Big Boobs’ to Linux Kernel.” Wired Enterprise, July 20, 2012. http://www.wired.com/wiredenterprise/2012/07/b16b00b5/.
McPherson, Tara. “Color Coding: Race and the Origins of Digital Media in Post-War U.S.” In Critical Code Studies 2010 Conference Proceedings. University of Southern California: Vectors Thoughtmesh, 2010. http://thoughtmesh.net/publish/380.php.
———. “Why Are the Digital Humanities so White?, Or, Thinking the Histories of Race and Computation.” In Debates in the Digital Humanities, edited by Matthew K. Gold, 136–60. Minneapolis: U of Minnesota Press, 2012.
Montfort, Nick, Patsy Baudoin, John Bell, Ian Bogost, Jeremy Douglass, Mark C. Marino, Michael Mateas, Casey Reas, Mark Sample, and Noah Vawter. 10 PRINT CHR$(205.5+RND(1)); : GOTO 10. The MIT Press, 2013.
Montfort, Nick, and Stephanie Strickland. “Cut to Fit the Tool-Spun Course.” Digital Humanities Quarterly 7, no. 1 (2013). http://www.digitalhumanities.org/dhq/vol/7/1/000149/000149.html.
Ramsay, Stephen. Algorithms Are Thoughts, Chainsaws Are Tools. Lincoln, Nebraska, 2010. http://vimeo.com/9790850.
Russo, Julie Levin. “thearchive2: The Slash Goggles Algorithm.” LiveJournal. thearchive2, April 10, 2008. http://community.livejournal.com/thearchive2/1465.html.
Sample, Mark L. “Criminal Code: Procedural Logic and Rhetorical Excess in Videogames.” Digital Humanities Quarterly 7., no. 1 (Preview2013). http://www.digitalhumanities.org/dhq/vol/7/1/000153/000153.html.
timothy. “GitHub Takes Down Satirical ‘C Plus Equality’ Language.” Slashdot. Accessed May 6, 2014. http://tech-beta.slashdot.org/story/13/12/14/1618239/github-takes-down-satirical-c-plus-equality-language.
Vee, Annette. “Proceduracy: Computer Code Writing in the Continuum of Literacy.” ProQuest LLC. 789 East Eisenhower Parkway, P.O. Box 1346, Ann Arbor, MI 48106. Tel: 800-521-0600; Web site: http://www.proquest.com/en-US/products/dissertations/individuals.shtml, 2010. http://www.eric.ed.gov/ERICWebPortal/detail?accno=ED523386.

 

Author Bio
Mark C. Marino is a writer and scholar of digital literature living in Los Angeles. He is the Director of Communication of the Electronic Literature Organization. He was also one of ten co-authors of 10 PRINT CHR$(205.5+RND(1)); : GOTO 10. His creative works include “Living Will,” “@OccupyMLA,” “a show of hands,” and “Marginalia in the Library of Babel.” He is an Associate Professor (Teching) in the Writing Program at the University of Southern California where he directs the Humanities and Critical Code Studies (HaCCS) Lab. His complete portfolio is here: http://markcmarino.com

 

Notes