January 9, 2006
A Digital MLA Snapshot
I have only brief notes from one session of the Modern Language Association Convention this year – the December 29 one on new media editing, chaired by Neil Fraistat of the University of Maryland, in which I presented “Toward Scholarly, Critical, and Variorum Editions of Computer Programs.” This was as tedious a paper title as one can imagine (sure to drive both computer enthusiasts and those in textual studies into slumber), but the other two speakers more than made us for this, presenting new interfaces to motion pictures (Stephen Mamber, UCLA) and a compelling take on how to approach video games via bibliography (Steven Jones, Loyola U. Chicago).
In my talk, I argued that “computer program” is a useful concept, and focus, for humanists studying new media. Computer programs are the most general, powerful formulation of what computers can do; they are expressive, and have been used for artistic and literary purposes for quite a while; and “computer programs,” as a concept, focuses on an important part of a system, just as the concept of a text provides focus. My hope was to build on Matt Kirschenbaum’s work in his 2002 article “Editing the Interface: Textual Studies and First Generation Electronic Objects” (still not online! arg!) by looking at computationally intensive works – not just Myst and Dragon’s Lair, addictive as they might be, but The Sims and Fable. I discussed re-issues (the 20th anniversary Infocom Hitchhiker’s Guide to the Galaxy), ports and reimplementations (to more powerful and less powerful platforms), mods and engines (from Quake to Half-Life to Counter-Strike and mods of it), and bug fixes. I also presented some examples of fan bibliography, such as the Infocom Bugs List, and commentary on source code – the Lions book being the main example there. I concluded with some specific editorial challenges for new media work and some discussion of the Electronic Literature Collection.
Before we began, the panel was photographed by a spy robot that briefly occupied the body and cell phone of Matt Kirschenbaum.
Stephen Mamber, a professor in the UCLA Department of Film and Television, showed several new ways to study and experience film, using the computer’s capabilities to help viewers question and think about cinema. One interface presented tiled pictures that could be resized – each one the first image in a shot from Hitchcock’s The Birds. Clicking on an image would play the shot, but the interface also made it easy to select a portion of the film to view and to look at a segment of it shot-for-shot. Another interface was hooked to Kubrick’s The Killing, augmenting it by offering a narrative map of the characters’ overlapping stories and a 3D models of the spaces in which the scenes took place. Finally, we saw the Center for Hidden Camera Research, where new media interfaces are used to interrogate surveillance footage.
Steven Jones, a professor of English at Loyola University Chicago, spoke next about how bibliographic methods could be thoughtfully used to understand video games – not treating them, of course, as books or purely as narratives. “Video” isn’t at the core of video games, he said, but serves to separate this object of study from textual studies. Video games, far from being self-contained, include encoding, platforms, social networks of players, and marketing and reception, as his main example, I Love Bees, demonstrates. This alternate reality game should be not only studied for its own sake, but should be part of the consideration of Halo 2, which it was designed to promote. Taking a step further, he suggested that ARG players act like textual editors in assessing evidence, comparing variants, and seeking something definitive. Bibliography can move beyond looking at variants and ports of games and into the lives of players.
Also of note from this year’s MLA: Some scenes from the Electronic Literature Organization get-together have been captured and placed online.
January 10th, 2006 at 7:41 am
I have some questions arising from this:
1) Given that “silicon is just frozen software” (Andy Grove, Intel co-founder), why do you describe “computer programs” as “an important part of a system”, instead of just stating that a digital computer, as a physical whole, is (functionally) identical with its program(s)?
2) The “just as” seems to imply only an analogous relationship between the concepts “computer program” and “text”. Why not just say that a computer program is a text?
3) Putting it together, why not just say that a digital computer is, very literally, a text?
Of course, it should also be pointed out that the reverse (a text is a digital computer) is false; but it sure would have been a great help to me if somebody had made that particular connection for me when I started out with “digital writing”.
January 10th, 2006 at 11:07 am
Very interesting questions, Dirk…
1) Given that “silicon is just frozen software” (Andy Grove, Intel co-founder), why do you describe “computer programs” as “an important part of a system”, instead of just stating that a digital computer, as a physical whole, is (functionally) identical with its program(s)?
A digital computer is a platform that can run many programs – something important to understand in order to see how platforms influence what runs on them, and to understand the formal and material nature of computing.
2) The “just as” seems to imply only an analogous relationship between the concepts “computer program” and “text”. Why not just say that a computer program is a text?
A text doesn’t have program semantics and doesn’t execute; making this “equation” would be overlooking the (new, interesting) things that computer programs do which texts don’t. Analogy isn’t identity; it’s a connection that recognizes how the analogy highlights certain aspects and hides others.
I’m all for making the connection, but in a way that helps us to understand computing vis-a-via texts, not in a way that collapses essential aspects of the former.
it should also be pointed out that the reverse (a text is a digital computer) is false
Presumably because digital computers do things that texts don’t? I think we may just disagree on what the word is is. I’d like to understand computer programs using textual studies, but not pretend that they are “just texts.”
At any rate, I don’t have a complete theory of how to understand programs via textual studies at this point, but I’ll be working towards in approach that captures something of the important nature of systems and programs, so I resist the “is.”
January 11th, 2006 at 9:02 am
Nick, I have no idea what to make of your reply. Honestly.
You say your project is “to understand programs via textual studies”, while denying that “computer program” is a subclass of “text”. How is this supposed to work? How can the toolset provided by textual studies be applied to entities that are not in the class for which the tools have been developed?
Let’s say you use that toolbox to compare two entities: (1) is Turing’s paper “On computable numbers, with an application to the Entscheidungsproblem”, and (2) is the Linux source code. How will you use textual studies to show that (2) “does” something that (1) doesn’t?
Actually, me saying that “(2) = (1)” is an exaggeration to the benefit of (2), since Turing’s theoretical machine is unbounded with regards to time and memory used, which clearly makes it more powerful than any of its real-world implementations. The fact that (2) has “program semantics” is fully due to the fact that (1) has the “meta-semantics” that are necessary and sufficient to define those “program semantics”. The fact that we now have physical machines which are able to interpret and execute the instructions inscribed into (2) is due to the fact that humans did interpret and execute the instructions inscribed into (1) first. Finally, the fact that no concievable class of digital computers, including yet-to-be-realized quantum computers, is able to exceed the limit posited by (1) is, well, simply one of the best-proven mathematical facts in existence. So, as I’m sorry to say (and I mean it: sorry!), your claim that “digital computers do things that texts don’t”, to me, lacks any foundation.
January 11th, 2006 at 10:12 am
Derek, I’m not Nick, but I have served as the conduit for a robotic spycam that once captured his image.
Despite the vague, amorphous name of the field, “textual studies” is not just the study of texts in some vague, loosey-goosey kind of way. It’s the specific scholarly discipline traditionally responsible for sifting amongst an author’s papers and manuscripts and making decisions about which version of a text either best reflects the author’s intentions (the old school approach) or else how to represent multiple versions within the limits of a printed book or (more recently) in electronic editions online. Every wonder why you walk into a bookstore to see ten different versions and editions of King Lear on sale? It’s because different scholars have reached different conclusions about what the text of King Lear actually is (note that we have no manuscripts of this or any other play surviving in Shakespeare’s own hand). The point is that in the process of doing this kind of work the discipline of textual studies has nurtured a very rich, mature conversation about the fundamental nature of texts, versions of texts, the ways texts interact with other texts as networks, their material dimension (what does it mean when an author doodles in the margins of a manuscript–is this part of “the text”), and so forth. Without meaning to speak for him, I suspect these are the kinds of insights Nick finds potentially rewarding in the study of computer programs.
January 11th, 2006 at 2:54 pm
Dirk, if you try running a compiler both on Turing’s paper and on the Linux source code, and then try booting what results, the difference will become clear right away.
As Matt says, textual studies is a rich approach. It’s not just pretending that things are texts and then discussing them. This approach can be applied (directly or by analogy) to objects of different sorts. In the case of programs, this approach can be applied with concern for how programs function when run on a computer, not just with an eye to their human dimensions of meaning.
January 11th, 2006 at 3:15 pm
Yikes, Dirk. Not Derek.
See, I created a variant. ;-)
January 12th, 2006 at 8:00 pm
A digital computer is a platform that can run many programs – something important to understand in order to see how platforms influence what runs on them, and to understand the formal and material nature of computing.
There’s no strict dividing line between a “platform” and a “program” though, except perhaps in the simplest cases. Obviously whether it’s in software or hardware isn’t the dividing line, because that’s a somewhat arbitrary decision driven mostly by cost considerations. Among software pieces, some seem relatively easy: The guts of Windows are part of the platform; as are your graphics drivers, the Java virtual machine, and the C runtime library. Are libraries you use part of the program or the platform, though? Whether something is a “library” or not is even kind of arbitrary, and mostly a software-engineering decision. For example, if I write a program that maintains a database of current facts, I suppose my program is keeping track of facts—but if I rewrite it to use a rule-chaining engine like Jess to do the maintenance, the facility of rule-chaining is really part of the platform, along with the filesystem, JVM, graphics drivers, and math library. And in principle nearly everything can be abstracted out into a library, leaving nothing for the program…
January 13th, 2006 at 5:25 am
Or, to go to the other extreme, you might just as well decide that your platform is the smallest physical implementation of a Turing Machine that is possible – I think the smallest one found so far is able to execute six instructions, and if you want to add I/O, it’s eight -, in which case everything else is the program!
None of which “means” anything to any machine that might be involved. The notion that anything other than “the human dimension of meaning” plays a role in computation is one that I believe to be very dangerous to buy into, because it mystifies computers, and draws attention away from “the man behind the curtain” (where it belongs, if you want to be able to call yourself “critical”).
January 13th, 2006 at 12:18 pm
I appreciate the replies, which encourage me to actually describe my approach thoroughly, in a paper, rather than a sentence. This will have to wait until other more pressing work is done, unfortunately, but maybe late next year, if I’m lucky…
It’s true, Mark, that platforms are different depending upon the perspective of different developers and users. This is important to any approach that takes platform into account, including mine. As to the idea that my critical approach mystifies computers, it would be hilarious if it were funny. This is a sure sign that the explanation I’ve given on here is far too sketchy to argue against, though.
January 13th, 2006 at 2:21 pm
Yeah, that’s one the perils of discussing academic subjects in the comments section of a message board I suppose. =] I was mostly arguing against a straight view of “there’s a computer system, and then programs run on them”, which your reply makes clear is not really your viewpoint anyway. I have read papers that seem to implicitly make a very strong assumption that “the program” is easily isolatable and the thing to be analyzed, which is the style of analysis I was reacting to.