In Week 4, Critical Code Studies contributors kept the magic alive as they discussed Wendy Hui Kyong Chun's "On Sourcery and Source Codes," the first chapter of her forthcoming Programmed Visions: Software and Memory. Informed by Chun's psychoanalytic reading and her awareness of the materiality of code work, the conversation deals with fetishism, gender, genetics, and performativity in ways both abstract and tangible.
Week 4 of the CCS discussion began with a reading from the first chapter of Wendy Hui Kyong Chun's recent book, Programmed Visions: Software and Memory. We are grateful to MIT Press for allowing us to share "On Sourcery and Source Codes" with readers here.
Reply by Jeremy Douglass on February 22, 2010 at 3:51pm
Wendy, thank you for this most enjoyable and provocative preview.
When you propose code as a site of magical thinking about causality, I'm wondering if your analysis is in contrast to other types of thinking, or if all attempts to situate causality are equally fetishistic. The reason I ask the question is neither to escape nor to embrace a "fetishistic" label for code studies thinking or for a code studies community. Instead, I'm trying to understand how the fetish for you differs (if at all) from its traditional enlightenment opposite, and what work you see this distinction doing.
In the context of your chapter, is code always approached as a fetish by those who create, read, or discuss it, or is it a fetish only to the extent that the person or group confronting code ignores contextual thinking about causality (platform studies, digital forensics, HCI cyberneticism, software engineering ethnography, etc.)? By comparison, is DNA (and various attempts to read, write, and discuss it) likewise a fetish, and does this change if considered in the complex context of RNA, general organic chemistry, etc.? Does the label of fetish apply to considerations of any site or system that is only part of larger a causal network, up to and including a controlled scientific experiment? Or is there a principle (whether in the mind of the subject or the presentation of the object) whereby some stances are more fetishistic than others?
I'm fascinated by the idea of code as fetish, but I'm also concerned about how the term "fetish" may be deployed in disciplinary disputes and topical territorialism. It is quite helpful to point out that old priests (and followers) are replaced by new priests (and followers). However, this point may ultimately be unproductive if the only alternatives to fetishistic thinking are either total information awareness or zero engagement. Such options re-inscribe a fetish culture with no outside (except perhaps an alternative priesthood of interdisciplinary academicians). Fairly good job security for priests.
The question I'm currently asking myself is, will thinking through code-as-fetish help people to adopt a plurality of new stances toward software and code? I can imagine how it might. However, I can also imagine it being deployed to dismiss all partial understandings and literacies as part of the impossibility of knowing. When Socrates tells Phaedrus the legend of Theuth (Plato 274e-275b), I'm left wondering if Phaedrus was convinced that we should abandon literacy altogether, and how that served him.
Reply Comment by Wendy Chun on February 23, 2010 at 6:09am
Yes. One understanding of source code as fetish stems from source code equals action, which sidesteps all the theoretical and historical work needed for this to happen. The second half of the book engages more with biology, and in terms of DNA, the answer again is yes (hence the rise of systematics).
To call something a fetish, though, is not simply to dismiss it. Indeed, the move at the very end is to see how (non)productive it can be - fetish gets us thinking about how things can go astray. It argues against Joseph Weizenbaum's reading of hackers as pathological and takes seriously Linus Torvald's claim that he wrote Linux "just for the fun of it."
The main aim, though, is to get us thinking about programmability and the ways in which this logic has been taken up as a way to negotiate an increasingly complex world. What is remarkable is its combination of rationality with mysticism, knowability with what is unknown.
In terms of disciplinarity, I think that thinking through questions of programmability and code are crucial. Critique, I believe, is about taking what you believe to be true (and love) and analyzing it, rather than looking for things to be dismissed.
So, the chapter is certainly not a dismissal of software or software studies. If anything, it's an argument that we need to engage software AND hardware (and their separation) as closely as possible, so we don't fall into a parody of Kittler's "There is No Software" or of corporate championing of software. That's why I make a case for software as a "thing" and also try to think through the limits of programmability.
Comment by David Shepard on February 23, 2010 at 8:10pm
To amplify your point about fetish, since a fetish is without reproductive pleasure (and transcendent meaning), when we read source code as an end in itself, a key factor that it is read for seems to be its exoticism. I tried to derive an analogy between "reproductive pleasure" and "execution," but even if such an analogy is unsuccessful, PERL poetry and Mez's work seems to function because of its ability to exoticize language more than the blurring of boundaries between surface/depth. What's interesting to me is that Java and Python poetry are rare. Python is known for clean syntax, something its partisans occasionally satirize PERL for lacking. The few examples of Python poetry I know of are bienalle.py, which is noteworthy because it is the only functional virus written in Python; World's first poem written in python: Wise Remembrances, a poem printed by a program that outputs its own source code; and the non-executable "Sonnets from Pythia," which don't seem to be available online. I think the complex, character-rich syntax of PERL is what makes it more appealing to code poets, whereas Python's syntax uses fewer non-alphanumeric characters and tends to be memorable more for its function than for how it transforms language. So could we say that the fetishistic aspect of code poetry seems to involve loading down language with something excessive that we see rarely in natural language, like typographical symbols?
Comment by Wendy Chun on February 25, 2010 at 1:37pm
Fantastic idea.
Comment by Mark Marino on February 23, 2010 at 10:13pm
Wendy,
When you speak of compilers and the act of compilation, you write:
Code does not always nor automatically do what it says, but it does so in a crafty, speculative manner in which meaning and action are both created. It carries with it the possibility of deviousness: our belief that compilers simply expand higher level commands - rather than alter or insert other behaviors - is simply that, a belief, one of the many that sustain computing as such.
You go on to challenge this vision of compilers or the compilation of language as involving a trivial transcoding that we imagine operates essentially without difference. I'd like to further tie your chapter into our ongoing discussions for the sake of bringing some side conversations into the main thread. Evan Buswell started a code critique where he offers an example of compiler breakdown, where the compilation is hardly transparent, equivalent, and without remnant. He writes about choices that were made in early C compilers before there was standardization.
One of these choices is with automatic conversions between different types of variables, for example between an "unsigned short int[eger]" and an "unsigned int[eger]." For the sake of clarity of explanation, imagine a machine on which a "short int" is three decimal digits, but an "int" is six decimal digits. If the "short int" is signed (i.e. it can be negative), then it can vary from -99 to 99, represented as 199 and 099, respectively (for those who noticed, you're right: this machine is not two's complement). The question that ANSI had to address (slightly simplified) was what happened when you added an "unsigned short int" to an "int". In either case, the result is the same, for example, on our theoretical machine 566 would become 000566. But the semantics of what happens to the int are different.
In a 1987 usenet thread, we find this somewhat related bug posted to comp.lang.c++:
#include
int a = -1;
unsigned b = 2;
inline int conv() { return b; }
main()
{
if (a > b) cout "(int) -1 > (unsigned) 2 ???n";
if (a > conv()) cout "(int) -1 > (int) (unsigned) 2 ????????n";
}
What happened is that both things get printed out; in both cases, -1 is found to be greater than 2.
What's happening is that the compiler sees b, an unsigned int---000002 on our machine---and converts -1, a signed int, into an unsigned int to match it---100001 on our machine. Since 100001 is bigger than 000002, both of these comparisons are true.
But the second one shouldn't be; that's the compiler error. Because a signed int is explicitly requested (by the int return type on conv()), that -1 should be compared with (signed) 2, and of course -1 is less than 2.
Buswell concludes:
These four elements - the programmer's somewhat ideal version of what something should mean, the compiler maintainer's idea of how something should be compiled, the actual compilation, and the way all of this actually works out on a real machine - are what in combination determine the meaning of any given piece of code. But the question is: how is meaning functioning within a system of code such that in some cases one of these is the "true" meaning, in other cases another is, and in some cases there is no canonical meaning? In code, what is the relationship of freedom of expression with expectations of meaning? How do the material and ideal interact in the meaning of code? Who ultimately gets to decide what a given statement means? And what can a dissenter do?
How well do you feel this characterization and example thrum with your argument?
Comment by Evan Buswell on February 25, 2010 at 10:53am
Thank you for drawing me into this discussion, Mark.
The above code critique came out of a Week 3 discussion in which - among other things - I was trying to highlight the difference and the interaction between the way a language community thinks their language works and the way their language actually produces meaning. The above critique is more focused on the actual, whereas I think Wendy's argument focuses more on the perceptual.
Although, now that I'm writing this, I'm not so sure. It seems like half of the time Wendy presents the fetishization of source code as the cultural product of our evolving and changing relationship to programming and computers. But in the other half, it seems to be a feature of the way code itself is constructed (and the Žižek quote supports that). I realize that these are not totally independent (they may be completely interdependent). But could you clarify, Wendy? To what extent is fetishization necessary in order to productively engage with code as it now stands? Do you think we could change this by changing our conceptualization of code or our relationship with code? Or would something about the way code itself works have to be altered? I suppose all of these questions assume that there's some sort of desirable outside to code as fetish, but I'm not really sure how to ask this without making that assumption.
"When individuals use money, they know very well that there is nothing magical about it-that money, in its materiality, is simply an expression of social relations.... on an everyday level, the individuals know very well that there are relations between people behind the relations between things. The problem is that in their social activity itself, in what they are doing, they are acting as if money, in its material reality is the immediate embodiment of wealth as such. They are fetishists in practice, not in theory. What they 'do not know,' what they misrecognize, is the fact that in their social reality itself-in the act of commodity exchange-they are guided by the fetishistic illusion" (Žižek 31).
Comment by Wendy Chun on February 25, 2010 at 1:38pm
What a great question: in terms of fetishization, I think that for now, to a certain extent, it is inextricably linked to the formulation of code as source code. I also think that code as fetish is only one way to think of source code differently. It's also a call for different conceptual models.
Comment by José Carlos Silvestre on February 22, 2010 at 3:56pm
One thing that might be overlooked here is the association of Logos with Presence and Intuition (in a Husserlian sense). When Faust, in the passage cited, tries to find the correct word behind "das Wort" (which, his intuition tells him, cannot be "the word"), he does not consult the original Greek, which would prove trivial for an erudite man of his time, and find the word "Logos." He instead expects the truth behind the text, i.e. Logos itself, to manifest itself to his spirit: he expects to have an Intuition of the Logos. That which the spirit tells him is truth; the written words ("das Wort") are corruption and deviation.
It is on these grounds that Derrida will associate Logocentrism with Phonocentrism - as Aristotle puts it in De Interpretatione, speech "translates the motions of the soul." This Presence - this "unconcealment of the Logos in the gleam of its presence" to the subject, or to the spirit - is absent in the world of code. I am reminded here of Katherine Hayles, in My Mother was a Computer, pointing out that code reduces ontological assumptions to a bare minimum; and, in How We Became Post-Human, positing that the Presence/Absence opposition has become insufficient, and introducing a "semiotic square" with Presence, Absence, Pattern, and Noise (249).
If code has become Logos, it has nevertheless become Logos without a spirit, without presence to a subject. It is not the Logos of the Stoics, or of Faust, or even of Heidegger.
Comment by Wendy Chun on February 23, 2010 at 6:16am
Yes, that is exactly what is so intriguing about it, and what makes the parallel point elsewhere. It is machinic repetition - writing par excellence - and yet, it is also posited as being "self-present" in terms of doing what it says, as pronouncing itself, as an "origin," but, as you note, there is no spirit / "father" behind logos. It is sovereignty without a sovereign. I see this as symptomatic of the logic of programmability, which I develop more in the rest of the book, especially in terms of the rise of genetics.
Comment by Jeff Nyhoff on February 22, 2010 at 10:34pm
Given my own oddly double background in theatre and computer science, my own close readings of Brenda Laurel's Computers as Theatre, and my love of computer history, I found many delightful points of engagement with this chapter.
I'd like to suggest that one of the more stubborn and problematic fetishistic illusions is the imagined "code space" that seems to lurk in such references to the location and operation of code as "backstage," "under the hood," "beneath the surface," "behind the screen," "behind/beneath the objects we manipulate on the screen," etc.
This chapter cites the example of persons "acting as if" money is magical, while knowing full well that it is not, whereby participants in this social relation become fetishists in "practice, not in theory." (A willful suspension of disbelief, then?)
However, in contrast, I find that it is very common for both end users and programmers to operate not only in practice but also in full belief in the reality of such illusory "code space."
Comment by Wendy Chun on February 23, 2010 at 6:27am
Yes, the relation of full belief to illusory belief is a great question. They are intriguingly linked by the question of action. Is it Kierkegaard who said that the best way to believe is to act as if one does?
Comment by Patsy Baudoin on February 23, 2010 at 7:29am
I'm very intrigued by your casting of the notion of programmability. I read it as akin to Walter Benjamin's notion of translatability, which allows Derrida, Butler, B. Johnson, and others to remark that the translation of a work is what makes of that work the original - before the translation, there was no original, no executed translation. Gérard Genette also proposed that a work was really the often intractable and ultimately un-limitable amalgam/total/grouping of its many versions/translations/interpretations. The notion that we seek sources in re-sources speaks volumes about the anthropomorphic vectors of desire and control in the realm of coding and programming.
Comment by Jeff Nyhoff on February 23, 2010 at 8:02am
Well, the notion of "acting as if" is at the heart of the so-called Stanislavskian "method" (of) acting, which is controversial in part because of the question of the degree to which actors should immerse themselves in the belief that the psychological states and physical actions of their characters are one and the same as their own during their performance on the stage or screen.
Relatedly, one of the things I find most disturbing about the GUI's celebrated "illusion of direct manipulation" (that I was happy to see you mention in your chapter) is that it is just that: an illusion. There is no such direct manipulation of the objects on the screen, of course. There is no Newtonian, mechanical causality at work between the end user's movements of the mouse and the movements of the mouse pointer on the screen, for example. And while most end users might maintain an awareness that the objects on the screen are not "real," I think that most end users truly believe that the directness of their manipulations of the screen objects is real. They do not usually think in terms of a system of code that is always already at work "between" the coordinated movements of their hand on the mouse and the "resulting" movements they see on the screen with their eye. (Except perhaps in those Brechtian moments when wildly moving the mouse no longer results in onscreen actions; when the computer is said to be "frozen.")
Accordingly, I think many are able to believe that "code" is trivial and irrelevant largely because they are able to believe that this code's residence and operations are both "behind the screen" and after the fact. That is, they believe that their screen manipulations are true and direct, and that these manipulations they find to be fully comprehensible within this tidily causal "screen space" are somehow subsequently translated magically into "code" somehow and somewhere back in that greasy/mechanical/geeky/menial backstage world that they are only too happy to be "screened off" from while they, the stars of the screen, directly perform their onscreen actions in the belief that they are freely and performatively performing the role of "self" or some other persona. But, as the myth of Zeuxis reminds us: the most compelling illusion created may be that of a screened-off backstage space when there actually is none. And the end user continues to not merely portray the stereotyped role of the "end user," whose actions and understanding are, by definition, so tightly constrained; rather, the end user remains immersed in that role, even after and between the performances of it. Like certain method actors who reached the point of no longer being able to detach their sense of their character from their sense of self.
Your chapter has set me to thinking again about the degree to which "programmers" also believe themselves to be performing the act of writing in(to) a magical, secret, backstage "code space," and as a kind of special, privileged persona, one that persists even after and between the performances of the role of "coder," in the act of coding, in the space of code.
I was also struck by how your historical narrative in this chapter wove (for me, anyway) such a palpable experience of character - not only of individuals but also of operant (often bigoted) stereotypes such as "coder" - and of the spaces in which the actions of programming and coding were performed.
I love your notion of "source" becoming source only "after the fact." As "re-source." Or, alternatively, as only a "re-presentation of action." Although, in that short phrase "representation of action," there are two highly contested and very slippery terms! Quite apart from the question of what an action is, there is the question of what it means to "represent an action," as well as the question of what it means to read/interpret/perform and/or believe in such a representation of action.
Your "source as re-source" also calls to mind how Shakespeare's dramatic texts (like so many others) were not written before performance but, rather, written through performance. Similarly, it seems to me that much of what we understand to be "source" code was actually written through repeated executions, not before execution. And, in this sense, is as much a retrospective, sedimented description of many repeated but varying actions/executions over time as a "pre-scription" for future action/execution.
And isn't this closer to the meanings that the term "hacker" tended to invoke in the era in which Weisenbaum was writing? Whereas, today, "hack" seems to me to be linked to that circular relationship between "code" and "end user" in the commercial GUI era of the past 25 years: where "code" is what(ever) the end user is not supposed to see/understand/modify, and an "end user" is one that must not see/know/change the code "behind"/"underneath" theGUI, lest that end user be charged with "hacking" the code - or, alternatively, with going backstage without a "backstage pass."
Comment by Mark Marino on February 23, 2010 at 8:03am
In my job as shepherd or sheep dog, I'll work to steer us toward using code to talk about code - a move in itself that may seem alternately obsessive, fetishistic, irritating, and pedantic - but I hope ultimately grounds our talk in encoded examples or code discourse - as I believe your intervention would posit it.
So as I read your writing, "software as logos establishes a perpetual oscillation between the two positions: every move to empower also enslaves" and also the dichotomy between the "all-powerful programmer, a subject who magically transforms words into things" and "slaves" or "clerks," I can't help being reminded of Will Crowther, recreating the cave that he loved, magically creating this inner world to explore (conjuring up magic rods and attacking dwarves) and at the same time wrestling with the junk trunk of Fortran, just trying to get the damn thing to work.
I wonder, are there material signs of those positions in ADVENT? Do we see that oscillation in our code critique thread? We certainly see that in the Climategate examples, right, Jeremy? That was a case of models and exasperation over the models and machines. Are there other examples of code passages that seem to live in this moment of imaginary power and all too real and material constraints?
I believe that double-position of possibility and hopelessness explains the irony and ironic dispositions I've come to know as a hallmark of programmers and is evidenced in the Week 2 discussion threads, the CCS haters (or skeptics), and on the posts of Stephen Ramsay's blog.
So let's talk through and with some code snippet examples or, if you will, circuit diagrams.
Comment by Jeremy Douglass on February 23, 2010 at 9:50am
Mark,
I certainly agree that Wendy's arguments about the power and abjection of coding resonate with the Climategate videos (e.g. Debunking Climategate 2/2 "Programmers, I've found, can have large, fragile egos"). But since there are already two code snippets in Wendy's chapter, I thought we might start there.
You may not be as excited about discussing these bits of code as some of the Code Critiques. Just as not all text is interesting in itself, not all code is interesting in itself - an assembly adder and a "hello world" are both more in the "See Jane run" category of language demonstration - useful, but not exegetically exciting.
Still, I think there is more than meta-discourse to have about Wendy's "Hello World." You mentioned in your CCS Week 1 presentation that
"Hello, World" has become the "Hello, World" of critical code studies. I've now seen readings of that in at least five articles and even more presentations that treat upon that program genre.
Let me be specific about how I read her example here, and what if anything I got out of it.
// this program spits out "hello world"
#include<iostream.h>
int main ()
{
cout"Hello World!";
return 0;
}
My first reaction was: "Spits?" That's not a rare verb to describe it in C and C++, but it definitely has a certain character. What is the provenance of this example? Is it from a textbook, or an online reference? Did Wendy write it herself? So I ran a search for the comment and first line, and found two hits - both previous work of Wendy's, indicating this snippet has its own history. Funny how the littlest things can make the most generic text specific.
My next reaction was to iostream, which told me this was C++: Why is it that almost every Hello World I ever see quoted is either in C or C++, regardless of the topical or historical context of the discussion? Certainly there are ready examples of Hello World in many languages, and I would expect people with interests in history / games / new media / academia etc. to use more examples such as Java, Python, Ruby, Lua - or Fortran for that matter. Looking at some of these examples, one thought occurs - the C and C++ examples are more verbose than almost any other language example, and even a bit Baroque. We may cite C/++ because of its recent paradigmatic dominance - but we may also keep using it because it does useful visual work on the page, declaring with many curls "Look, I'm code!"
My final reaction was reflecting on the absence of a single comma - "Hello World" vs. "Hello, World." Without going too far down that rabbit hole, there is a distinction (for example, I had to account for this in my searching), and we find consistent inconsistency about the comma across the entire "Hello World" culture. In general, the first phrase tends to refer to the program, and the second sometimes indicates the output, as for example in the current Wikipedia entry for Hello World: "A "Hello World" program is a computer program which prints out "Hello, world!" on a display device."
The distinction between code and data allows for drift, but also introduces subtleties. For example, looking back at Wendy's code, we can see that the comment is not accurate in describing what the code does - possibly through carelessness, but more probably because writing the comment text entirely in lower case and the output in emphatic title case was a matter of style.
Comment by Wendy Chun on February 23, 2010 at 10:04am
I would also want us to get us thinking about the difference between this snippet, which charts the movement of data through a computer and the higher level A+B:
li r3,1 *load the number 1 into register 3
li r4,2 *load the number 2 into register 4
add r5,r4,r3 *add r3 to r4 and store the result in r5
stw r5,sum(rtoc) *store the contents of r5 (i.e. 3)into the memory location
*called "sum"s (where sum is defined elsewhere)
blr *end of this snippet of code
And also the logic diagram: if notB and notA, do CMD1 (state P); if notB and notA and notZ OR B and A (state Q) then command 2.
This diagram brings out how this conditional is not as simple as its translation (involves several negative gates because at one point NANDs were much easier to make than ANDs). It also highlights the fact that hardware is not outside logos (understood as logic). As Phil Agre points out, a lot has to happen in terms of timing etc. in order to make transistors act properly as logic gates.
Comment by Mark Marino on February 25, 2010 at 1:42pm
I was doing a little poking around, too, for that particular version of "Hello World" and came across this discussion forum, where a programmer is trying to get a version of that program to compile in C++ and has written the following code.
#include
main(){
cout"helloworld";
}
As I was reading through the replies, I encountered some interesting material for our code studies "in the wild" conversation from Week 2.
At some point, Greg P. replies:
Yes, this is most likely the problem. You should also make main() int main()
and return 0 at the end (before closing brace):
#include
int main()
{
std::cout "Hello Rahul Gandhi!" std::flush;
return(0);
}
Others reply, responding to the superfluous and potentially confusing use of ( ) around the 0. Conversation ensues about whether it is necessary to return 0 in the first place.
Greg replies:
Oh, and all my colleagues hassle me about my parenthesis. I was taught this early on by some old farts and it has since stuck to me. There is no harm, and it's purely a stylistic view. The same argument could be said about K&R coding style (which I have barely just got un-accustomed to). Please don't badger me on my style =)
K&R coding style refers to the formatting in Kernighan and Ritchie's book The C Programming Language, which gives the rules for indentation and line breaks, a topic we've discussed elsewhere and that no doubt will play a key role in CCS.
Attila Feher replies:
All my point was (no badgering! 🙂 ) is that if you show this to a newbie he might think that the parenthesis are required and that return in main, too. My point is rather that IMHO it is preferable to give that little speech about "it is not mandatory to return but it is a good style to do so, because...". Well, I dunno any good excuses for the parentheses. 😉
Chris adds:
Don't want to encourage too many parentheses else people might mistake your code for lisp 🙂
Attila then re-emerges under the username "White Wolf" and adds:
They reminded me of lips. Time to get a girlfriend again. 🙂
Another member turns to the books:
From the standard, 6.3.3 (ISO/IEC 14882:2203):
"Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value returning function."
Greg P. replies,
lol! You are all right. I have never looked at my returns in that light. I guess it's time for me to "re-adjust" my coding style if I plan to be helping the rookies out there =)
I bring this in because the discussion of this line of code brings out so many aspects of code culture. Here is the programmer, disciplined by his peers when he attempts to offer help. His anxiety about being badgered, his allusions to the "old farts," the fact that others have already tried to correct him on that point. The (pejorative?) reference to lisp, which become lips, which returns us to the lonely (and here presumably male, heterosexual) programming geek. All material to chew on.
By the way, at some point the respondent "Agent Mulder" uses this convention to quote a previous comment, another sign of the bleed of code or markup into writing:
I thought the C++ standard said we don't have to bother returning 0 at the end, as it is done automatically?
This is not to distract our discussion but to once again demonstrate the role that initiating into language that is "Hello World" is an initiation into cultures of programming as well.
Reply by Micha Cárdenas/Azdel Slade on February 24, 2010 at 3:47pm
Hello Wendy,
When you say "Code does not always nor automatically do what it says, but it does so in a crafty, speculative manner in which meaning and action are both created," it brings me back to a question I posted in another thread, but which I want to continue a bit. It seems to me that new media art, as you discuss in your elephant example, cannot be reduced to code or software, in many cases. For example, in my collaboration with Elle Mehrmand, technesexual, we use code to read biometric sensors on our bodies and produce audio from them as we engage in erotic acts. In fact, I would say that in our work we try to activate or bring to life something which is unquantifiable, irreducible to code, through the interaction of our bodies and our software and our hardware, that is, affect, the erotic, anticipation, and intimacy.
So, if we think that code creates both meaning and action, that when executed code creates a material change in the world, moving bits and atoms, then could we see critical code studies as bridging the divide between deconstruction and ontology? Elizabeth Grosz writes, in her book Time Travels,
Psychoanalysis and deconstruction, today preeminent forms of interpretation and analysis within the humanities, restrict themselves to the inside of representation, which provides its own vested "reading" of an outside or a real as always already codified, or only accessible through some kind of representational codification. It is for this reason, I believe, that Deleuze's work, which is not particularly feminist, may be of tremendous use for feminist politics: it is his concentration on the ontological questions, on the problems raised by matter, by force, by power, by time for thought - by what he sometimes calls "the outside" - that may provide a new direction for a more abstract approach to feminism, the kind of abstraction that is needed to bring about new frames of reference and new kinds of questions. (173)
This passage is challenging to me personally, as someone who's worked a lot on deconstruction and on ontology, in that it privileges ontology as more real, and reifies the separation between these two disciplines. I wonder, as I have earlier in this forum, if some of the drive towards code studies is in line with this desire to get closer to the real by looking at code. Yet perhaps critical code studies in the way you have formulated it, meaning AND action, can bridge this divide.
Additionally, the line, "Making code the source also entails reducing hardware to memory and thus erasing the existence and possibility of hardware algorithms," was interesting to me, thinking of technesexual, because we use Arduino and other electronics in our performances. Therefore, much of our code, the Arduino portion, although in an abstract language, involves direct hardware access, like these lines:
// TURN*ON the temperature sensor
pinMode(tempSensorPwrPin, OUTPUT);
digitalWrite(tempSensorPwrPin, HIGH);
...
delay(250);
sensorValue = analogRead(sensorPin);
Serial.print(sensorValue, BYTE);
I wonder if we can think of the growing usage of DIY electronics as bringing back a "close to the hardware" practice into contemporary artistic practices? We also definitely put important parts of the logic into the hardware as well, the wiring and circuits, which you can see here (though we don't have a schematic handy).
As for Galloway's quote - "to see code as subjectively performative or enunciative is to anthropomorphize it, to project it onto the rubric of psychology, rather than to understand it through its own logic of ‘calculation' or ‘command'" (321) - doesn't that assume a logic of calculation or command? Again, thinking of technesexual, and biometric code in general, why not think of a logic of modulating signals, bridging and connecting bodies and worlds? And why should we think that a circuit board designed by human desires and processes is separate from a rubric of psychology?
One last point I'd like to raise is about context. Thinking back to the blind men and the elephant of new media, it seems that the code for many new media projects is unremarkable without knowing the context. A project I've worked on with Ricardo Dominguez, Brett Stalbaum and Ama Sara Carroll, the Transborder Immigrant Tool, is a good example of this. Here's a code snippet from that project:
/**
* Static factory method producing a GpxRoute from a Vector of Waypoints and
* the name of the route. Automatically calculated the bounds from the waypoints
* vector.
* @param waypoints
* @param routeName
* @return the new GpxRoute
*/
public static GpxRoute makeRoute(Vector waypoints, String routeName) {
GpxRoute rte = new GpxRoute(waypoints,routeName,0,0,0,0);
rte.updateBounds();
return rte;
}
In the hands of your average urbanite, this code is unremarkable, and code much like it is likely in the pockets of most readers of this post. Yet in our case, the code enables (will enable once it is deployed) people crossing the US/Mexico border to navigate to a safety point and find water, hopefully finding a route to survival and to a lessening of economic, gender based, or any host of oppressions. So here, the context is essential to understanding what action and meaning is produced by our code. Who uses it, where they use it, and when, are all critical to any understanding of this code. Also, this code, as it is Java, goes through a different path than the code we have been discussing up to this point. It is not simply compiled to machine code, but it is actually compiled into bytecode and then made executable only at run time by the java virtual machine. There are many other executable paths between human readable code and machine code if we consider other kinds of scripting languages like Perl or PHP and their individual runtime behaviors.
Reply by Wendy Chun on February 25, 2010 at 1:40pm
Fascinating post. I agree with most of it - my move to questions of process (Fuller's work etc.) is precisely to move away from code as the ground for new media studies and to argue for a certain ephemerality, a certain vaporiness. In terms of hardware, there are so many questions because hardware does not simply or easily get us away from logos (which is the topic of chapter 4). I think, however, that quantum computing and other non-strictly programmable systems are intriguing.
Reply by Mark Marino on February 24, 2010 at 9:44pm
Wendy,
I keep reading and savoring this chapter. At the same time, I recognize a kind of discord between your formulation of "sourcery" and the fetishization of source code and the tasks we have undertaken here.
My first reaction is to wonder, as others have here, if your formulation isn't a repudiation of our project. But you've already laid that to rest (as you also did by accepting our invitation).
But I also need to understand how your correction of the misunderstanding of source code might affect a reading.
For example, take any of the examples we have posted in the working group or even your "Hello World" example, and demonstrate for us what it would mean to interpret that object, that source code, and not erase execution.
Again, I have this terrible habit of reading books like yours, Kate Hayles', Alex Galloway's, Matt Kirschenbaum's and saying, "Aha! Now we've gotten to the bottom of it! This is the truest realization of the functioning of these systems, Wendy is an electrical engineer by training, we finally have a sense of the way these systems work." (No doubt, the result of my own disciplined and punished experience of the academy).
And at the same time I hate to say that all theory has to be "operational."
But I can't help wonder, and you see from my comments that I'm fixated at this point, if your formulation doesn't suggest the study of the source code as something always lacking - and maybe I'm echoing Jeremy here.
I don't want to say, what is a good reading of code, except that I do get some sense that you envision a discussion of the code and software free from this "sourcery." I'm just not seeing a lot of examples of that in this particular chapter.
Comment by Wendy Chun on February 25, 2010 at 1:41pm
I think what CCS is doing is important and fascinating and plays with source code in intriguing ways. The point of source code as "fetish" - as opposed to simple source - is that source code does things / can be read in ways not limited to its "final function." At the same time, I'm wary of claims that source code is everything because it erases the question of execution, process, etc., but I don't think that this is what CCS is doing.
Reply by Jessica Pressman on February 26, 2010 at 11:00am
In response to Mark's questions about the nature of Wendy's critique in relation to CSS, I think that this chapter argues for and proves the importance of reading code and software - and, indeed, all digital objects and creations - and to do so more often and from different angles. What I particularly appreciate about the chapter is the way it opens up software studies or CSS to analysis that is cultural and historical in nature. I am neither a programmer nor reader of code - and am also attuned to and wary of the move that Chun critiques as a desire to assume that code is hard to keep and "difficult to capture" and thus more authentic or true - so I appreciate her unpacking of code as something that "emerges" historically and possesses multiple layers that themselves can be analyzed: "In order to emerge as a language or a source, software and the ‘languages' on which it relies had to become iterable." Recognizing the iterability of these languages means recognizing the need to critically study them.
Reply by Mark Marino on February 24, 2010 at 10:11pm
As another thread, I've been looking at a particular line in your chapter:
Programming languages enabled the separation of instruction from machine, of imperative from action, a move that fostered the change in the name of the source code itself, from 'pseudo' to 'source.' Pseudo-code intriguingly stood both for the code as language and for the code as program (i.e. source code).
This recalled for the moment in our discussion of ADVENTURE, when we turned to this line:
CALL IFILE (1, 'TEXT')
It is an injunction which certainly evokes the expectation of a "yes, sir" from somewhere in the machine. Yet when programmers tried to implement this version of ADVENTURE, they had to rewrite that line or recreate a function called IFILE. It was otherwise undefined in the program or the available documentation of that specific version of Fortran. "Where was that documentation? Where was IFILE specified?" Jeremy and I wondered.
Dennis replied:
I believe the IFILE subroutine was highly machine-dependent, carrying on some of the functions that we would probably expect an operating system to handle through a driver, but of course this was in an era where the concepts we understand by those terms were still developing. Was the missing subroutine so well-known that at BBN Crowther would have expected everyone to have a copy? Did Woods recognize it as an ad-hoc routine that he knew wouldn't work at Stanford, so he didn't bother to save a copy (either back in the 70s, or thirty years later when he made certain files from his student backup accessible to me)?
So, to answer your questions fully, Mark, we'd need to ask platform-studies questions, rather than strictly CCS questions.
For Jeremy and me it was a moment where we started to ask ourselves, what can we call our object of study. Where, if ever, can we draw the lines and say, as you suggest is always partial, this is the source code, this is the text.
It was instructive to me that we hit upon this moment where a source code question could not be isolated from the machines that executed it. However, in my reply to Dennis and in my Week 1 remarks, I tried to indicate that I don't see such disciplinary distinctions as productive and don't want to be involved in conversations where someone slaps my hand and says, "Ah-ah, that's hardware."
So again, I see your chapter as offering, among many other things, a way of bridging that conversation between the nominally divided research areas of software studies, platform studies, Jerzian studies, Kirschenbaumian forensics, etc. - an opportunity to acknowledge that to study code is to study one set of signs in a network of operations, interactions, interconnections, and "ecologies" (as Craig Dietrich put it the other day in a presentation).
Again, for me, this does not suggest the impossibility of discussing source code as text but the impossibility of discussing it in isolation - or that when we do that we are always examining the footprint and not the foot (though I believe you formulate that idea with more grace and nuance).
Reply by Evan Buswell on February 25, 2010 at 3:25pm
Wendy,
In a presentation at the Society for Social Studies of Science annual meeting ("Truth and Command in the Language of Code," Proceedings of 4S, 2009), I recently made a very similar argument: I argued that because of the way code is constructed, the declarative and the imperative are conflated, and so a line like "C = A + B" means both "add A to B, store in C" and "C is equal to the result of adding A to B"; that is, the result is assumed as soon as the command is given ("yes, sir!"); command thereby has a truth value and becomes control.
But lately I've been reconsidering the scope of that argument. I still think it's true of a functional, declarative language like Haskell. Haskell does its best to destroy any so-called "side-effects," to swallow the result entirely into each expression, and to have some sort of universality apart from all specific machines. But I'm not so sure about a language like C. Consider the presence of such things as the standard C function setjmp, which stores a program location in a variable for the purpose of transferring execution to some other part of the program, then getting the thread of execution back after who-knows-what has occurred (see this (pdf), section 7.13). It's hard to see where exactly the result of that is represented, or where the completeness of the action is assumed. Further, and more relevant to Wendy's argument, there is at least one programmer (Eric S. Raymond) who argues that C is an abstraction of the von Neumann machine, not an abstraction of calculation as such (see this). I think setjmp exemplifies this; it seems to have been added to the C language for the purposes of representing some capability of the machine that is left out of the core language.
If source code is an abstraction of the machine, I feel like the notion of code-as-fetish may be in danger of repeating the Platonic distaste for art - although I think Wendy is resisting that. As Jeremy mentioned, in the Phaedrus, Socrates strangely seems to condemn all writing as derivative, a replacement (supplement) of the original form, one step too far away. There is, clearly, a tendency for a representation to replace and obscure what it represents, but isn't there also the possibility for a representation to illuminate what it represents? If C is an abstraction from the von Neumann architecture, then why not think about how it illuminates the fundamental assumptions of that architecture, rather than about how it hides all of the specifics of each implementation? Couldn't looking at assembly language programming be a bit like the blind men and the elephant: the big picture is only clarified when we are finally able to see the assembly code illuminated as an illustrative C program?
Ultimately, I think that the fetishization of programming languages can be found in the function-happy C language - after all, what is a function but precisely the fetish that represents an action as the magically complete and concrete result? - I just suspect that there may be other things going on that fight against this fetishization.
Reply by José Carlos Silvestre on February 25, 2010 at 3:48pm
I apologize to Mark if I briefly depart from practical examples. I hope this leads us back to specific pieces of code and circuitry soon. But Wendy's chapter got me thinking, and there are some points in theory I would like to ask her opinion on.
I guess that much behind the apparently negative connotations in "code as sourcery" or "code as fetish" stem from working implicitly from Theodor Adorno's Dialektik der Auflkärung - namely, the assumption of a historical tendency, from polytheism to modern technics, of a disenchantment of the world. Code as enchantment, in this latter stage, thus comes off as a weird form of retrocess.
The association of modern technics with Logocentrism is not itself new, naturally: it is a direct corollary of Adorno's Aufklärung, and Heidegger has repeatedly stated that modern technics is an effective conclusion of metaphysics, that is to say, of the history of Logocentrism. But there are points in which Heidegger's account of this journey differs from Adorno's, and I'm trying right now to think through the ideas in your chapter from a more Heideggerian point of view.
In "The Question Concerning Technology," Heidegger calls Enframing (Ge-stell) "the essence of technology," and defines it thus:
Enframing (Ge-stell) means the gathering together of the setting-upon that sets upon man, i.e., challenges him forth, to reveal the actual, in the mode of ordering, as standing-reserve (Bestand). (113)
In earlier works, Ge-stell receives slightly different definitions. This standing-reserve (Bestand) refers to the concealment of being, as it is reduced to its function in the Enframing. It is not difficult to see how this subjugation of the world as mere instruments for a subject is a continuation of the (Logocentric) metaphysical journey.
It is technics that reveals the world in its facticity, that is to say, makes it possible to determine the indeterminable to a caring (Besorge) subject with the support of equipment (Zeug) in the mode of calculation - and it is tempting to link Heidegger's "facticity" with our modern "virtuality." So far, code as Logos is an easy extrapolation: as the machinery itself is abstracted out - or rather, reduced to standing-reserve - code becomes self-present, "doing what it says," iterable and predictable, existing in a microcosm of its own invention, i.e., in facticity.
But then there is the strangeness I pointed out earlier on: that if this is Logos, this is Logos without Presence, Logos that does not unconceal itself to the subject (like the spirit that murmurs correct translations to Faust, this Logos too has detached itself and presents itself now as resourceful Mephistopheles, as an other). In "The Principle of Identity," Heidegger writes:
Enframing no longer concerns us as something that is present - therefore Enframing seems at first strange. It remains strange above all because it is not an ultimate, but rather first gives us that which prevails throughout the constellation of being and man.
One should be reminded that Heidegger rejects an understanding of technology in terms of means and ends, understanding it instead as a mode of revealing (eine Weise des Entbergens), a "poiesis" just as art is poeisis. Enframing plays a dual role, as well: at the same time, man lives under the "perennial risk" of being himself reduced to standing-reserve, and thus losing his subjectivity; at the same time, it is only by a true understanding of Enframing that man can be truly free. It is also relevant that Enframing, as a mode of revealing even conceals itself - the concealment we see clearly in the fetishism that conceals hardware and lower levels of software.
I don't know if these issues are addressed elsewhere in the book, but here it goes. Speaking of "fetishism" and "sourcery" tacitly acknowledges a narrative of Enlightenment, whereas this triumph of the Logos by concealing being into standing-reserve is argued by Heidegger to be the very essence of technics, rather than a modern deviation. Where do you stand on this? Also, do you see something essentially novel about code-as-logos, or just a culmination of a process of technics-qua-enlightenment/completion of metaphysics"?
Reply by Mark Marino on February 25, 2010 at 11:42pm
Wendy, let me start another thread that I believe Jessica Pressman will be taking up shortly.
She was remarking that the distinctions you make in the hierarchy of women computer operators in the early days of computing is instructive. I wonder if in the parallel your juxtaposition draws, they take the place of "execution" or "executives" or if they are more like "source code." (Perhaps you did not intend such a basic substitution.) Certainly your note about not conflating the source code with execution seems to align with your historical intervention for us not to conflate the presence of women in the room with computers with their status as programmers.
When I was researching Turing in my chatbot work, I came across a piece by Joan Clarke (Murray) in the book Codebreakers, where she offers an account of her time in Hut 8, working with the backroom boys on decryption.
A few notable passages include:
In my first week they put an extra table in for me in the room occupied by Turing, Kendrick, and Twinn. According to Good, I rose from the ranks of the girls in the big room; but this was obviously because of my degree, and before I had any chance proving myself. I think it was Kendrick who said, 'Welcome to the sahibs' room.(Clarke quoted in Hinsley 114)
Very soon I worked a night shift alone in Hut 8, and I felt quite important 'minding the Baby.'
She goes on to recount her work "'twiddling' on messages" to decrypt them using the Baby, "a small special-purpose machine, made by the British Tabulating Machine Company."
My next promotion was apparently harder to negotiate, possibly because of my sex, although there was another female mathematical cryptanalyst, working in the Cottage.
Inevitably the duller routine clerical work was done by women, since only men with what were considered suitable qualifications for cryptanalysis or related translation and intelligence work could join GC&CS instead of being conscripted into the armed forces. (Clarke quoted in Hinsley 115)
Even as an analyst, she was in the position of a student. When Turing (a.k.a. Professor) wrote up his Enigma methods, Joan "was the guinea-pig, to test whether his explanation and worked example were understandable, and [her] task included using this method on half of the material, not used in the example" (quoted in Hinsley 116).
Clarke's work primarily dealt with executing a procedure known as Banburismus, a system for decryption devised by Turing. They were named so because "the cipher texts were recorded as punched holes on long sheets of paper, made of Banbury." She also recounts that "Leslie Yoxall devised a statistical attack...This was known as Yoxallismus. My own contribution, a day or two later, greatly speeded up the routine solutions, but my name was not attached to it: I was told to my surprise, that I had used 'pure Dillyismus.'" (quoted in Hinsley 117). This latter system was named for Dillwyn (Dilly) Knox.
It is interesting, the ways in which these processes and algorithms become the eponymous legacy of their developers (or, in the case of Banburismus, signs of the medium through which they were enacted). The not-naming that Clarke offers in this narrative is a perceivable sting. Certainly this un/naming speaks for the connection between the human processor and the automated process. But it is also remarkable how one of her specific contributions is effaced because she had innovated the same process that another analyst had devised. How ironic, considering Turing's own work on the Entscheidungs problem was trumped, in a sense, by Alonzo Church's Lambda Calculus, if Hodges' history is to be believed. This is not to diminish Turing's contribution, nor Clarke's. We remember Turing's solution for the novelty of his procedure, its retro-active foresight. We remember the innovation of the men of Hut 8, name processes for them, and consequently, originality in the realm of computational machines remains, in the general sense, a fetish.
Although she does not belabor this moment of lost credit and diminished authority, her next sentence begins, "Chores performed in slack periods included removing pins and tearing up the Banbury sheets." Feels like an account of technological domestication and subjugation.
Reply by Jessica Pressman on February 26, 2010 at 11:17am
I have been reading (savoring, really) this chapter and working to get my ideas together into a coherent post since the chapter deserves at least that kind of attention. As Mark mentioned, I was excited by the political (and particularly feminist) interventions this chapter makes and compels us to consider. Wendy's chapter has a sense of urgency about it that is unassuming but inescapable. This chapter intervenes in media studies at an important time to remind us of the gendered codes through which computing history and objects are presented and considered. Wendy continues her important work from Control and Freedom by interrogating the ways through which we read and draw conclusions and, moreover, the kinds of elisions we make in the process. As Mark mentioned, I want to draw our attention to the point Wendy makes about the elision between feminization and feminism. She argues, "we need to move beyond recognizing these women as programmers and the resonances between computers and the feminine. Such recognition alone establishes a powerful sorcery, in which programming is celebrated at the exact moment that programmers become incapable of ‘understanding' the machine." Here, Wendy puts her finger on the critical move of feminizing the machine that has traditionally been seen as a recuperative act of/infusion of feminism into computing history. But in Chun's deconstruction, such acts become themselves deserving of critique.
Let me add that Wendy's focus on logos and rhetoric ties in nicely with John Guillory's recent essay in Critical Inquiry, "The Genesis of the Media Concept." In that essay, Guillory charts a genealogy for media studies that remains mindful of the reasons why the word "media" is a rather recent development in the far longer history of media studies. When Wendy claims that "source code only becomes a source after the fact," she is practicing a kind of Guillory-style of analysis that interrogates larger systems of meaning-production. She writes, "Source code is more accurately a re-source"; this implies, I think, that our readings of code construct us as subjects, as critics in the act of reading. Thus, we need to be attentive to our acts of reading as political, historical, and cultural practices.
Reply by David Shepard on March 2, 2010 at 8:39pm
Jessica writes, "Source code is more accurately a re-source"; this implies, I think, that our readings of code construct us as subjects, as critics in the act of reading. Thus, we need to be attentive to our acts of reading as political, historical, and cultural practices.
Along the same lines, where might we situate the emergence of close analyses of technology in relationship to our history, especially in its relationship to the development of specific technologies? The emergence of close analyses of high tech, like CCS, and like N. Katherine Hayles' Writing Machines and medium-specific analysis seems to have only come about as technologies become homogenized. For example, Writing Machines appeared in 2002, as all media were becoming digital.
Critical Code Studies seems to be emerging as code (and hardware, especially) are becoming more homogenous. In the 1980s, there was a plurality of hardware operating systems and programming languages, and yet only now do we become interested in "code" when our computers and programming practices are becoming increasingly similar. In the 1980s, scholarly discourse on technology seemed focused on abstract concepts like hypertext and critical theory, aside from general technical theory like Kittler's work. The 1980s offered a lot more choices for operating systems: DOS, Mac OS, CP/M, Wang OS, OS/2, and NeXTStep. Now, Windows and Mac OS X have become the dominant operating systems, and yet concomitantly, close readings of technology have emerged. Hardware is more homogenous as well, since Macs went from Motorola processors to Intel. The gaming market has also become more compressed, and Platform Studies is now an emerging discipline.
Is the reason for the proliferation of discourse around the specifics of hardware and software partially the result of technology becoming more familiar? The relative compatibility of computers has made them more prevalent and yet less diverse. My question seems to be, then, do we begin to see code (and technology) as a relatively unified concrete object of knowledge as it becomes less diverse? It's easier to reify code as a unified object of knowledge once there's less variety, and this is one of the techno-historical criteria that affects our readings of code.
Reply by Jessica Pressman on February 26, 2010 at 11:27am
Also, the section on female programmers at ENIAC reminds me of the history of typewriting; for the term "typewriter" first referred to the person (the amanuensis) doing the writing at the machine and then later came to identify the machine itself (see Leah Price's edited collection Literary Secretaries/Secretarial Culture and Darren Wershler-Henry's The Iron Whim: A Fragmented History of Typewriting). So there is an interesting parallel here in the history of writing machines and the kind of gendered pathways toward media evolution that they take and the stories we tell about them.
Reply by Zach Blas on February 26, 2010 at 4:55pm
Hi Wendy!
I want to talk about magic in this post. It is everywhere in this chapter: from the concept of "sourcery" to all the historical examples and quotes you provide on black magic, black art, wizards, and priesthoods.
A striking quote you use from Joseph Weizenbaum: "instrumental reason ‘has made out of words a fetish surrounded by black magic. And only the magicians have the rights of the initiated. Only they can say what words mean. And they play with words and they deceive us.'"
Sourcery is source code made fetish. You offer us a definition of the fetish from the Oxford English Dictionary: "an ornament or charm worshipped by ‘primitive peoples…on account of its supposed inherent magical powers.'"
You follow the magical here when you write:
to program in a higher level language is to enter a magical world - it is to enter a world of logos, in which one's code faithfully represents one's intentions, albeit through its blind repetition rather than its ‘living' status.
Now that I've laid out these quotes, I see a link between how historically magic has been used as a metaphor / way of describing programming's history and the way you are deploying magic in your text. That is, magic, to me, seems primarily relegated to the negative register here: it is the causal generator of obfuscation, blackboxing, and "our screen's ghostly images."
My question is: why do you stay with these uses of magic historically attached to programming? Is there something in magic worth fighting for? I guess I'd like to think there is. Are there other types of magic that would be detrimental to lose?
You end this chapter stating that "the fact that we cannot know software can be an enabling condition: a way for us to engage the surprises generated by a programmability that…cannot entirely make the future and the past coincide." This certainly seems to be gesturing toward a type of "magic," but not identified as such.
Again, when discussing hacking, you suggest it is "a fetish that always leads us astray." If the fetish is magical (in the OED sense), like you have pointed out, then is hacking not another type of magic? A different magic from sourcery?
Perhaps in the end, this question is more conceptually driven: why only use the magical terms in line with their historically negative connotations and not also use this rhetoric of magic to gesture toward the (affirmative) potentialities programming / coding can offer?
Reply by Micha Cárdenas/Azdel Slade on February 28, 2010 at 10:59am
Zach,
Your question, for me, brings up Ricardo Dominguez's idea of Mayan Technology. Hopefully he'll jump in and say more about this, but my understanding of his telling of Mayan Technology is that it is represented by the little Zapatista boy who waves a stick at the Mexican military jets overhead and makes them go away. Mayan Technology implies that there are always effects of technology that are unintended, emergent, and unanticipated, which a strict literal, real interpretation cannot see, but which can stem from intention and imagination. Perhaps Arthur C. Clarke's Third Law that "any sufficiently advanced technology is indistinguishable from magic" has a great deal of relevance here. Where some new media artists, including myself, often think of ourselves as subverting technologies towards unintended uses or driving them towards hypertrophy, I've been wondering recently if this isn't a more common part of the workings of technology, when in the HASTAC forum on queer and feminist new media spaces it seems that the disparity between designers/engineers' heteronormative assumptions and the reality of a proliferation of queer uses of new media seems to demonstrate this.
I think Wendy acknowledges this and is pointing towards this when she says:
The point is not to break free from this sourcery, but rather to play with the ways in which logos also invokes "spellbinding powers of enchantment, mesmerizing fascination, and alchemical transformation." The point is to make our computers more productively spectral by exploiting the unexpected possibilities of source code as fetish.
The fetish of source code, then, is to turn it into logos and then to think that it operates transparently, clearly, on face value and that it can be read as pure functionality, but instead Wendy encourages us to bring out the spectral dimension of code, to unleash the unexplainable, to try to read in code the unspoken effects and meanings in the code, which can be a result of many things, such as the wildness of electricity that lies at the basis of any circuit and the messy intensive materiality that circuits read as analog signals or the outside spirits of other desires, forces, and power structures that possess bodies of code. I imagine here Avital Ronell's channeling of the many voices of spirits in the telephone as an essential precursor to this kind of technological analysis-as-spirit-medium. It is also interesting that while much has been said about the technological shaman, it seems that less has been said about the technological medium. The two traditions differ significantly: looking at the writings of say, Michael Taussig, shamans are those who transform into other creatures in order to travel to other places, but mediums are those who become literally medium, an instrument of transmissions, a listening ear for spirits, receptive to signals, invaginated.
Reply by Craig Dietrich on February 28, 2010 at 10:20pm
Hi all,
I'm excited that Micha brought up a distinction between the spiritual/magical potential of "medium" and the more-emphasized "technological shamen." For the Magic project (whose relationship to this discussion is coincidental yet very intriguing), we conducted interviews at last summer's NEH Vectors Institute, a month of rapid prototyping of digital humanities projects between cultural specialists and technologies. I looked at the archive and a couple of quotes stand out that both enlighten and confuse my thinking about who and what cause/control unintended, emergent, and unanticipated effects. In an interview, Elizabeth Losh describes how her video was transformed by the addition of a video-annotation player:
Today was the magical moment. Actually seeing the prototype and the video running in it was amazing to me because I shot that video a day and a half ago, and to see it not only running in a player but the fact that I had this whole ability to annotate it and to have it speak in ways other than the speaker is speaking. In other words, it can speak in terms of the system of the essay itself - the online text - because I can mark it up with meta data.
The transformation wasn't magical in the sense of turning one thing into another, but rather the different technologies (video and annotation player) and content (video and annotations) revealed a fascination when they were brought together (in the form of an annotated video).
We also had interviews that spoke to the wizardry of technologists. In the context of the shaman who transforms to travel to other places, when a programmer conjures up a game-changing algorithm, does this take the project to a new place? David Shorter describes a moment in his project's development:
After my latest meeting this morning I actually feel like, in some ways [the Vectors tech team] broke the DaVinci code, and this might actually be a very workable model within a week, which is crazy to think about. In intellectual labor we think a project - writing and editing - could take a long time. But in a programmer's world I have a feeling that once they break a code or learn how to hack something (which I think they just did) it makes everything, ‘Okay, Great! Now we're good to go…" you sort of bust through a moment.
The coders here will point out that this isn't what really happened: a lot of time, effort, and creativity went into writing the project's code, but to the non-programmer (David) it appeared to be a single conjuring. Though, if the roles were reversed, I would imagine the technologist would see similar magic: David conjuring up a ground-breaking notion in anthropology during a meeting.
Whether fetishizing the medium or seeing magic in the work of others, the net effect, at least in these interviews, is excitement. Sure, we can rebuke astrologists for not sticking to science, but they have much more intimate relationships with the objects in the sky than the average person. Perhaps we can promote the positive, spectral aspects of code - "unleash the unexplainable" - to build interest, resulting in a better understanding of systems that drive most of our daily routine?
Reply by Ricardo Dominquez on March 1, 2010 at 6:55am
Thanks for letting EDT (Electronic Disturbance Theater) play specter in this dialogue about code performativitie(s). Indeed, part of the history of our code gestures has been about pushing the politics of code qua code towards a question of code qua body, code qua race, and code qua magic (Mayan Technology) - an affective code that re-links the gender(s), e-race, and class that effective code politics often erases as outside of the power of code qua code. In 1998 new media artists Brett Stalbaum and Carmin Karsic created FloodNet, the first virtual sit-in code that we used all of 1998 in support of the Zapatistas in Chiapas, Mexico and their battle against the neo-liberal policies of NAFTA. These e-actions gained deep responses from a wide net of communities: from the DOD launching the first known "infoweapon" to hackers and net.activist calling this gesture "pure evil." By 1999 many groups from the Left began to use the FloodNet code, which we had distributed at the start of the year with our Disturbance Developers Kit. One question that was often asked was will those on the Right or who are against our politics use the code. What occurred on the message boards of the various hate groups like the Aryan Brotherhood types was that they decided not to use the FloodNet code because it "smelled of brown." Here code becomes haunted by the force of a meta-space that is almost like magic - where one fetish - that of "whiteness" - was disabled by the fetish of "code."
Here is a the FloodNet code from an e-action we did with Iranian activists a few years ago:
/* define global variables */
var locid = new Array(16);
var message;
var delay;
var pollspeed = 0;
var speedid = new Array(3);
var polltime = new Array (3);
var reloadctr = 1;
function init() {
locid[0]='http://www.president.ir/farsi/images/header.jpg';
locid[1]='http://www.president.ir/democracy';
locid[2]='http://www.president.ir/eng/ahmadinejad/speeches/images/titlee.jpg';
locid[3]='http://www.president.ir/humanRights';
locid[4]='http://www.president.ir/farsi/ahmadinejad/archive/di-dakheli/1385/di-35/im-1/s6.jpg';
locid[5]='http://www.president.ir/equality';
locid[6]='http://www.president.ir/ahmadinejad/cronicnews/1385/03/24/image/a013.jpg';
locid[7]='http://www.president.ir/freedom';
locid[8]='http://www.president.ir/farsi/images/header.jpg';
locid[9]='http://www.president.ir/justice';
locid[10]='http://www.president.ir/farsi/ahmadinejad/archive/di-dakheli/1385/di-35/im-1/s6.jpg';
locid[11]='http://www.president.ir/free-speech';
locid[12]='http://www.president.ir/eng/images/header.jpg';
locid[13]='http://www.president.ir/barabari';
locid[14]='http://www.president.ir/farsi/ahmadinejad/duties/images/title.jpg';
locid[15]='http://www.president.ir/azadi';
/* */
speedid[0]='Slow dialup';
speedid[1]='Fast dialup';
speedid[2]='High speed';
polltime[0]=6;
polltime[1]=3;
polltime[2]=1;
delay = polltime[pollspeed] * 1000;
}
function pageshift() {
var stringstore;
var counter;
stringstore = locid[0];
for (counter=0;counter<15;counter++) {
locid[counter] = locid[(counter+1)];
}
locid[15] = stringstore;
reloadctr++;
return;
}
Here it is in action.
http://www.thing.net/~rdom/iran/index.html
Reply by Gregory Bringman on February 27, 2010 at 7:14am
Wendy,
Thanks so much for your thoughtful investigation that is quite a pleasure to read. Having a history in which human "computers" give their récits while machine computers claim their role as intermediaries between an a posteriori source code and a runtime context that imbues this code with a sense of "action" is quite wonderful.
In regard to the notion that the fetishizing of source code follows from the leap made from this code to its runtime effects, without considering compilation or interpretation, I wonder where the psychoanalytical concept of the mirror and mirror stage fits in this jump over material realities that make execution possible. The body as an object of desire is in a sense executed by its observation of itself in its reflection, but mirrors aren't exactly ever really "transparent," while it is the mirror that makes the image of the self, like source code, possible. The mirror also reflects backward to those who gaze upon it rather than acts as a window that is free of dirt or other coatings - the mirror is opaque, like a filtered pane of glass.
That said, given that we project onto source code its executability, and given your mention of the transformation of words into things, I was wondering if you were familiar with the 17th and 18th century universal language movements and their possible contribution to this discussion. Specifically, I was wondering where you think the tradition of "pasigraphies" might fit into a writing, code, or inscription that is "executable." Pasigraphies were components of artificial languages in which words were constructed as direct mappings onto so-called universal taxonomies of knowledge. Each category, genus, or species might correspond to a single letter or syllable, letters or syllables that were then arranged into words which could be pronounced or written given additional rules of syntax. In this way, things were transformed into words and communication, then stretched beyond idiom to a pointing, by speech or writing, to a vast order of things in which only space, not time, would be necessary in communication.
Do you see fetishization in artificial languages? Can an external world that provides a source for a taxonomy then be said to be the intermediary between a classification scheme and executable words which "run" off this classification scheme?
Reply by Frederica Frabetti on February 27, 2010 at 11:04am
Wendy,
Thank you very much for sharing this wonderful chapter. I am looking forward to reading the whole book!
I am very much interested in your perspective on performativity and the way you complicate the account of code as performative. I have always had a few problems with Galloway's (and partly Hayles') idea that code is performative in a much more direct or literal way than language - not only because I do not necessarily believe that there is such a thing as "code in general" that can be pitched against "language in general" (this deserves a discussion in its own right, I think), but mainly because I do have problems with analyses of code/software that layer something metaphorical/immaterial on top of something literal/material. Isn't language material? Isn't code material?
So thank you for bringing back complexity (and the workings of mediation) into the performativity of code.
I am very interested in asking you this question: you hint at the constitution of (the dream of) a sovereign subject in code - which is what the performative does, according to Butler and others. What do you think is the subject constituted in code?
At the end of the chapter you mention "the computer, the program or the user" as intentional authorial subjects possibly constituted through the erasure of execution. I agree with your view, but at the same time I wonder: is this the same as saying that these subjects are constituted through the performativity of code?
And also, how do we distinguish between these different subjects? For instance, how is the performativity of code in which, say, the user is constituted different from the performativity of code in which the computer or the programmer are constituted as subjects?
I am asking this because it seems to me that if we say that code is performative, of course the question is going to be ‘what is the subject that is constituted through code?' I am persuaded that thinking of code as performative makes a lot of sense, and I am currently trying to investigate the implications of the citationality of code. Therefore, I am very interested in knowing your opinion on this specific point.
Thanks also for steering the debate toward what, for me, is only apparently a more theoretical approach. In fact, it seems to me that your chapter powerfully shows how ‘reading code' cannot be done without at the same time problematizing this very act of reading.
Reply by Julie Meloni on February 28, 2010 at 9:02am
I've said elsewhere that I'm not particularly able to move these conversations forward—I'm still nothing more than a very interested observer, trying to find intersections in my own scholarly work, if there are any at all. To that end, I just wanted to highlight (and thank) those whose comments in this thread have been particularly illuminating:
Jessica Pressman's comment about how this chapter "opens up software studies or CSS to analysis that is cultural and historical in nature." She then goes on to say that she is neither a programmer nor a reader of code. However, I am. Yet I find myself far more interested in these sorts of cultural and historical analyses than I am almost anything else it seems. The iterability of the languages, absolutely, is something that I can use, and I am grateful for the way it is handled in this particular chapter.
Similarly, Patsy Baudoin's comment helped make some connections for me, as she brought up Benjamin's notion of translatability - and Genette made an important appearance as well. This isn't the first time Genette has been mentioned in discussions here: there was a mention of paratext in a thread critiquing "Random Mazes" and Gregory Bringman proposed adding Mimologiques: Voyage en Cratylie to the bibliography (and/or Mimologics translation by Thais E. Morgan). If I'm not mistaken, I think it's in Mimologics that Genette gets at the sorts of things Patsy brings up in her comment. Even if not, I think it's interesting (and important and useful) that CCS and Book History can use Genette in similar ways.
Finally, I was glad to see comments by Jeff Nyhoff and Zac Blas. Both comment on the presence of magic throughout the chapter. Zac's question/comment about using the rhetoric of magic to talk about the "(affirmative) potentialities programming / coding can offer" is an interesting one to me in terms the greater conversation about "doing" CCS. In my professional programming life, I've had to negotiate "magic" from all sorts of angles: from other developers I was working with (invested in keeping their work secret for various reasons of power and control) to those giving the orders ("it's magic, right? just make it happen") but who also invoked the corporate gaze. I don't really know where I'm going with that other than to say the rhetoric of magic carries some weight, to be sure.
Anyway, like others in this thread, I am sincerely looking forward to reading the entire book.
Reply by Liz Losh on March 21, 2010 at 10:25pm
I think that your point about the romanticizing of female computers from the historical past is certainly a good one, and you are right to encourage critical thinking about the way that the trope of the female computer represents "direct programming," which involves wiring connections and setting values without reliance on written code, thus suggesting that this historical narrative dramatizes an absence of literacy rather than a proto-literacy to be celebrated.
I might add that in California the JPL archive indicates that female computers also had a unique role working with the unit of the keyframe, which evolved out of their earlier experiences plotting telemetry, according to their oral histories.
The advent of electronic computers slowly changed what the all-female computations group did. The women were trained to program in FORTRAN, the primary computer language developed for scientific applications. Sue Finley, hired into the group in 1958, remembers that the male engineers largely didn't want to do the programming themselves in the 1960s. It was still considered ‘women's work,' not part of an engineer's job description. So the group began to code and run programs for calculating trajectories to the planets, for various Earth orbits and other tasks assigned them by the Lab's engineers.
New computers didn't change the fact that data were still plotted by hand. Electronic computers couldn't plot data until the 1970s. ‘I worked on Ranger 3 telemetry by hand,' recalls Finley. 'The computer wasn't working that night. JPL's Al Hibbs read it to me over the phone and I plotted it. When everyone realized that Ranger 3 hadn't reached escape velocity and wouldn't reach the moon, I went home. I got there around six in the morning and my husband was watching the news. They had a little blackboard up with the numbers I had calculated on it. I said ‘Those are my numbers!' Almost nobody in the outside world knew we women did that work.'
What's interesting to me is that after plotting by hand was no longer necessary, the female computers reported that "engineers started to want computer animated movies to help promote missions" that showed not only the trajectories but also "views of the planets during spacecraft flybys." Eventually, some of the women hired as computers moved into less sex-segregated fields like software engineering, but tasks related to data representation and information visualization with a temporal axis continued to be seen as women's work for many years.
I suppose my question might be how much is "women's work" in relation to computation region-specific and a response to local conditions of gender and labor rather than an absolute expression of ideology constituted by a subject's relation to logos? People have written about female computers in relationship to existing cultures of telephone operators and others who hand-wired connections. Was this particular turn in what female computers were called upon to do at JPL shaped by the fact that in-between animation was already seen as appropriate labor for women elsewhere in the Southland?
Works Cited
Adorno, Theodor. Dialectic of Enlightenment [Dialektik der Auflkärung]. Tr. by Edmund Jephcott. Stanford: Stanford University Press, 2002.
Agre, Phil. Computation and Human Experience. Cambridge: Cambridge University Press, 1997. Print.
Benjamin, Walter. "The Task of the Translator: An introduction to the translation of Baudelaire's Tableaux Parisiens.'" Tr. by Harry Zohn in Translation Studies Reader. Ed. by Lawrence Venuti. Routledge, 1999. Print.
Clarke, Arthur C. Profiles of the Future: An Enquiry into the Limits of the Possible. Harper & Row, 1973. Print.
Galloway, Alexander. "Language Wants to be Overlooked: On Software and Ideology." Journal of Visual Culture 5(2006):315-331. Print.
Genette, Gerard. Mimologiques: Voyage en Cratylie. Editions de Seuil, Paris, 1976. Print.
Grosz, Elizabeth. Time Travels: Feminism, Nature, Power. Durham, NC: Duke University Press, 2005. Print.
Guillory, John "The Genesis of the Media Concept." Critical Inquiry 36.2 (Winter 2010): 321-362. Print.
Hayles, N. Katherine. How We Became Post-Human: Virtual Bodies in Cybernetics, Literature, and Informatics. Chicago: University of Chicago Press, 1999. Print.
---. My Mother was a Computer: Digital Subjects and Literary Texts. Chicago: University of Chicago Press, 2005. Print.
---. Writing Machines. Boston, MA: MIT Press, 2002. Print.
Heidegger, Martin. "The Principle of Identity." Identity and Difference. Tr. Joan Stambaugh. New York: Harper & Row, 1969. Print.
---. "The Question Concerning Technology." The Question Concerning Technology and Other Essays. Tr. by William Lovitt. New York: Harper & Row, 1977. Print.
Hinsely, Francis Harry and Alan Stripp, eds. Codebreakers: The Inside Story of Bletchley Park. Oxford: Oxford University Press, 1994. Print.
Kernighan, Brian W. and Dennis M. Ritchie. The C Programming Language. Upper Saddle River, NJ: Prentice Hall, 1978. Print.
Kittler, Friedrich. "There is No Software." CTHEORY. a032 (1995). Web.
Laurel, Brenda. Computers as Theatre. Boston, MA: Addison-Wesley Professional, 1991. Print.
Plato. Phaedrus. Tr. and Ed. R. Hackforth. Cambridge: Cambridge University Press, 1972. Print.
Price, Leah and Pamela Turschwell, eds. Literary Secretaries/Secretarial Culture. Hampshire: Ashgate Publishing Limited, 2005. Print.
Ronell, Avital. The Telephone Book: technology-schizophrenia-electric speech. Lincoln: University of Nebraska Press, 1989. Print.
Weizenbaum, Joseph. Computer Power and Human Reason: From Judgment to Calculation. San Francisco, CA: W.H. Freeman, 1976. Print.
Wershler-Henry, Darren. The Iron Whim: A Fragmented History of Typewriting. Ithaca, NY: Cornell University Press, 2007. Print.
Žižek, Slavoj. The Sublime Object of Ideology. New York: Verso, 1989. Print.