By Alex Gil, Code Critique, Liz Losh, Ryan Shaw, and James (Gottlieb) Smith | March 9, 2012
- Derri(co)da by Alex Gil
I want to explore the ways in which critical discourse in general and literary criticism in particular are already procedural, and what it would mean to write code to express and critique natural language discourse. The can of worms I feel I am opening has been opened before in many different contexts, going as far back as Aristotle in my estimation. We could justify my intervention by claiming that any code we could generate to express or critique natural language discourse can itself be critiqued back from a CCS point of view. The process looks something like this:
Human Discourse –> Analogical Code –> Code Critique
The example texts have been collected under the title, Ulysse gramophone/Deux mots pour Joyce by Jacques Derrida, and published by Éditions Galilée in 1987….In these studies, both originally delivered as talks, Derrida makes several moves that made him an irresistible target for my meditations on discourse and procedure. Read Full Post Here
- DIY Coding, by Liz Losh
For the past two years I have been teaching Processing [a free and open source computer programming language] to creative writers who usually have no previous computer programming experience in college courses like this one on Digital Poetics that focuses on experimental forms of writing for the screen, and I have been consistently pleased with the outcome. Even poets who describe themselves as radical “non-techies” or outright “Luddites” are able to complete projects, thanks to the simple programming interface of Processing.
In an interview, one of the creators of Processing, UCLA Professor Casey Reas explained why Processing is so accessible to complete beginners as a “low floor, high ceiling” language. He credits its success to the immediacy of feedback, which is so central to a minimalist design that features large “stop” and “play” buttons familiar to anyone who has ever used a VCR or DVD machine. As Reas explains, “You can write one line of code and see it run to see a result.” He argues that this kind of visual gratification provides an immediate “motivation to beginners” in a “medium that they care about.” Read Full Post Here.
- On Tenure and Code, by Ryan Shaw
Last week I attended a meeting to discuss changes in tenure and promotion policies at UNC…. The discussion had turned to new forms of scholarship and how to assess their significance or influence. I pointed out that computer scientists seem to have solved this problem. They write software that demonstrates some new algorithm or technique, and often they will make this software available as open source software to be used by other researchers. (This is quite common in the natural language processing community, for example.) Those other researchers may know the work upon which they are building primarily through their use of the software that embodies it, rather than through reading papers. Arguably, then, the software is the primary scholarly product.
So, how do these scientists assess impact in this brave new world in which software code has replaced words on paper as the medium of scholarly communication? Well, usually they write a technical report, post it on the same website that their software can be downloaded from, and kindly request that it be cited by others who publish work for which the software was used. The technical report might get “officially” published in conference proceedings, or it might not: what matters is that it provides a surrogate for the “real” scholarly product, a surrogate that fits neatly into existing networks of dissemination, citation, and evaluation.
…this last idea–that digital work needed to “stand on its own”–stuck in my mind. It echoed assertions I’ve seen many times in the “hack vs. yack” DH permathread, that code “speaks for itself.” “And the more I think about it the more I am convinced that this is the wrong way to think about digital scholarship, because no scholarship, no creative and productive work, “stands on its own” or “speaks for itself.” Read Full Post Here.
- Coding and Digital Humanities, by James (Gottlieb) Smith
….A digital humanist afraid of the digital is like a scholar of French literature who is afraid of French. You can’t be a digital humanist if you don’t understand the digital. That doesn’t mean you have to be able to code any more than being a scholar of French literature means you have to be able to write French literature. You just have to be able to understand the nuances of what you’re studying and how you are studying it. Otherwise, how can you properly interpret the results?
What I have learned over the years is that programming and writing are different in one important aspect: programming scales differently than literature. This one important rule is what explains much of the confusion humanists have about programming, and it’s something that programmers must learn if they are to rise above being just a programmer…..It doesn’t matter what language the developer uses to write the program, you still need to draw the right lines. You still need to find the common elements and split them off into their own libraries. You need to understand the organizing principles at play and how they impact the project.
In literature, it’s not the person with the largest vocabulary who writes the best books, but the best storyteller. You can be the best coder in the world, but if you choose the wrong structure, you’ll produce a worse program than a poor coder who selects the right structure.” Read Full Post Here.