Peter's first comment:

My academic background more or less precludes my participation in the theoretical side of things so I'll delve right into my primary interests: obfuscated code and the production of pseudo-texts. Usually, the obfuscated code does something incredibly simple, like redirecting from one website to another but takes an incredibly round-about way to do so. The "obfuscated" nature of code is obvious to any half-decent programmer: it lacks any sort of "elegance" (believe it or not, this is an important concern for many computer scientists!). But how do you sum up elegance? You can only *really* tell by truly understanding how well the code accomplishes its task.

So if elegance is all about how the code accomplishes the task, what do we make of code designed to do something really irritating? While brainstorming for the forum, I happened to mention that a lot of content-based spam filters can be avoided by creating "pseudo-texts" that resemble English but make little or no sense (I'm sure everyone's seen plenty of this in their inbox). What one can do is take a whole bunch of examples of "good" text (text that passes through the spam filter) and use a statistical model to string words together in a way that looks legitimate but is almost pure nonsense. This text is used to disguise the spam payload. Below is some text generated by a simple trigram-based language model trained on the text generated by the co-hosts of this forum and I (plus some well known CCS texts):

"instead of elegance. lev manovich in the conversations in order to do the conversion. been re-reading old programming primers to get started on your hastac blog discussing your interest in critical code scholars. matthew fuller generously shared software studies collection forthcoming. code can never be executed. within ccs, and extending them. cultivating procedural literacy the obama campaign‚ who do modelling should be included. here is an understanding that the lisp list processing languages developed for artificial intelligence software does and how it's a new kind of contextual."

What do you think? To me, it's almost a simulacrum of the actual conversation... Hopefully I've thrown enough out there to garner some interest. I think it's essential to remember that code is process not product... Can you analyze it in isolation from its product? Does it matter?

As the forum progresses, I can go into some detail about how I constructed the language model, how it can be improved and I'll also provide some obfuscated code examples in the code analysis sub-forum.

Jarah's First Comment:

My interest in CCS is at a meta level - particularly in the programmer's embodiment of the code. How does the person writing the code bring notions of the world into the code itself? How does a team of programmers impact everyday life? What happens to the body once the code is written? executed?

Code for everyday digital technologies is (usually) written by a human, or a group of humans, who have preconceived notions about the world, their own common senses and knowledges, their own understandings of categories and values that enable them to do their work according to best practices and web-standardizations. The categories, coding and programmer together function as surveillance, displacing those on the margins, rendering them invisible.

I would like to begin a conversation around these questions- how does embedded normativity within the code itself render the content inaccessible? or doesn't it? How are our physical bodies rendered in code? How do raced and gendered and sexualized inequities get carried over wholesale to digital spaces? What do we learn when we read the code that 'represents' us?

What does it mean to read the code for the Facebook user profile? And what part do you read- the original code, the executed code, or the css? For example:

<body class="ego_page home hasLeftCol fbx safari4 mac Locale_en_US">

The Facebook user profile has a body class title of 'ego_page' - which describes the essence of the page's meaning- the profile you create is all about your own ego- you decide what information goes on there to describe your identity/ies - you portray yourself the way you would like to be seen. Or so it seems.

BUT… the developers trust the user to write-in their current city and hometown, political views, religion and even a bio into a blank text box. Sex is an option, but male and female are the only (problematic) drop-down choices. There is no gender option. Additionally, a user can only be interested in women and/or men, and can be ‘looking for’ friendship, dating, a relationship or networking. There are no choices for one-night-stands or S&M, no choice of being gendered queer, or sexed as intersex.

Facebook also gives users interesting choices for relationship status: standard ones such as married, single, in a relationship, engaged, widowed, separated, and divorced, plus ‘its complicated,’ and ‘in an open relationship.’ These last two, presumably, are to allow people to define themselves outside the mainstream of sexual relationships.

What I find interesting is that the ‘open’ relationship is a values-based relationship; there are many people in this country who would find this reprehensible, yet it exists. So why then is the sex category locked down as a binary, and why aren’t there any gender choices? Additionally, why is the primary relationship status based only on sexual relationships? While there
is a ‘family’ category, it is not given the same visual opportunities for placement in the user profile, thereby reducing other non-sexual relationships to a lesser status. The contradictions between implied primary sexuality, and the enforced heteronormativity reduce the Facebook user profile to the historically representational instead of lived, actual embodiments.

Would it matter if the body tag was called something else? What meanings are gained and lost through the word choice in the body class?

Facebook developers also make choices on what code elements to include and what to exclude, in this case, choosing to code drop-down menus instead of text boxes, thereby making choices about how information is collected. (see my post here )

The new open source social networking site Diaspora has chosen to user a text box instead of a drop-down menu to collect information about gender. By simply changing the input for gender into a text box, the individual developer made a space for those who are not normatively gendered. Her reasoning and the arguments against it are at the level of the code, through the common senses of the programmers themselves.

Interestingly, the arguments against gender as a text box are directly related to Mark Merino's explanation of operational code vs. data in Hello World:

"the computer does not understand what it says. Literally speaking, the computer does not even interpret that code. When the function is called, the computer will print (output) the list of the two atoms (as symbolic units are called in Lisp) "Hello" and "World." The single quotation marks tell the computer not to interpret the words "Hello" and "World" (as the double quotation marks do in this sentence). With this distinction, language becomes divided between the operational code and data. The computer here merely shuffles the words as so many strings of data. It does not interpret, only uses those strings. However, those words in quotation marks are significant to us, the humans who read the code. "Hello" and "World" have significance, just as the function name "print" has a significance that goes far beyond its instructions to the computer and gestures toward a material culture of ink and writing surfaces."

In the case of the Diaspora gender text box and the Facebook drop-down sex menu, the information collected is in quotes, and only interpreted by the humans who read it, not the code that collects it. The code itself is always already socially interpreted by the humans who write it. What agency does this give the reader of the original code? the reader of the page after code execution? How are other 'common senses' and knowledges carried over into the code via the programmers and developers? How does this inform the actions and inactions of people using the site?


Richard's First Comment
I approach Critical Code Studies from two directions. First, as someone who studied computer science as an undergraduate, I have an obvious technical interest as someone who has read and written a good deal of code myself. In this sense, I'm mostly interested in how we judge the aesthetics of code, how we understand code as we read it, and how it is written--in short, the more technical aspects of programming. These are extremely important questions given the increasing role of code in our everyday lives, and I believe that CCS holds out the possibility of being genuinely helpful to programmers. This is, to be sure, a fairly narrow, technical perspective, but it is one which I believe is important.

However, I also approach CCS as an historian, and it is here that I find not only . There is by now a well-established tradition within the field of history of treating non-traditional sources as texts--a practice which is itself drawn from cultural anthropology. This is exemplified in works like Clifford Geertz's "Deep Play: Notes on the Balinese Cockfight" and Robert Darnton's The Great Cat Massacre , in which the authors unpack cultural symbolism inherent in a local tradition and an unusual event, respectively. I believe that this sort of hermeneutic analysis is highly relevant to Critical Code Studies. To understand the code, we must analyze the culture, traditions, practices, and discourses surrounding it. By the same token, CCS may allow us to reach new insights about the broader culture, not only that of programmers but of society itself.

Finally, I am interested, as I detail in my blog post, in CCS because it offers a way to analyze texts and discourses which are constrained by rigid rulesets (the rulesets themselves, of course, are also texts). Code is not the only discourse where this is the case. Games and mathematical proofs both come to mind, as, to a somewhat lesser extent, does science in general. I am curious what others think of this: can CCS be generalized to other constrained discourses? If so, how?


Mark's first comment
Over the past few years, I've watched Critical Code Studies grow from a provocation on Writer Response Theory [] into a rappidly growing and expanding area of inquiry with scholars producing readings that amaze me with their insights and their sensitivity to nuances of language, subtleties of hardware, and deployment of critical tools. The Critical Code Studies Working Group and conference at USC were particularly rich, as I expect this discussion will be. At times, I'd like to just stop and watch. But I can't. I continually find myself attracted to the challenges within the practice, the seeming bridge-too-far, not the low-lying fruit but that oh-so-sweet stuff in the upper branches perilously out of reach (a metaphor suggested by a forerunner of CCS Loss Pequeno Glazier).

Lately, that fruit has focused on the act of "interpretation" of signs particularly with regard to their natural language affinities. Some call these attempts "dangerous." Others see them as inciting another Science War. I certainly do not mean to pick any fights and have no desire to dump theory all over the computer lab. If anything, I see in CCS the potential to bring DH scholars and computer scientists together in collaborations and meaningful dialogue. At risk of creating an "us" and "them," I'm so happy to see Stephanie August of Loyola Marymount University and Todd Millstein of UCLA have agreed to join us today, and I hope there are other computer science folks and programmers in the discussion as well. I have the suspicion that the most interesting readings in CCS will be done by people who self-identify as computer-scientists (with humanities leanings), though the collaboration across the disciplines is even more exciting and quite in keeping with HASTAC's mission.

Again, in my own work, despite my interest in this collaboration, I tend to explore the contested edges of the discussion rather than the comfortable middle, and my latest post on the Critical Code Studies blog (re-posted in HASTAC for easier discussion) [] once again returns to the question of the meaning in some of the arbitrary aspects of the code. In this discussion I explore metaphorical interpretations and resonance, using techniques from the humanities that are often disquieting to those who program for a living. I see gems of discussion while they see sloppy architecture, poorly patched solutions, unsustainable nightmares of underdocumented hack jobs.

I will let the post explain my basic argument so that I can instead thank our HASTAC Scholars, the guests, mentors, and, in particular, Fiona for offering this wonderful venue for the exploration of CCS.