Gerfried Stocker & Christine Schšpf (2003), eds., Code - The Language of Our Time, Ars Electronica, Linz: Hatje Cantz. Codes are essentially closed systems of semiotic elements - like all language codes. The texts which are formulated in these languages (or programs) are 'performative' strings of signifiers (summarising Leo Findeisen's statement in 'Some Code to Die for: on the birth of the Free Software Movement in 1887', in Stocker & Schšpf, 2003: 74). New codes are introduced and superseded all the time. Replacing the old code of English (if only), Findeisen points to two key historical examples: the new world alphabet 'VolapŸk' (1874), and in turn another 'universal language' introduced by Zamenhof (in 1887) as a predessor of 'Esperanto" (first congress in 1905). Zamenhof stated at the beginning of the manual of use: 'An international language should be, as any national one is, be a common possession, which is why the author is here resigning for all time his personal rights over it.' (in Findeisen, 2003: 82) These examples all operate under the principle that language belongs to the public sphere. Note: If the same might be said of software, one might wish to make a distinction here between 'open source' and 'free software' - open source necessarily implying the free distribution of its source code whereas free software need not necessarily go this far. See http://www.opensource.org/ and then http://www.fsf.org/ for more detail (and for results that contradict this to some extent as both seem to say that free licensed distribution is necessary and access to source code). -- Florian Cramer (2003), "Exe.cut[up]able statements: the Insistence of Code', in Gerfried Stocker & Christine Schšpf, eds., Code - The Language of Our Time, Ars Electronica, Linz: Hatje Cantz, pp. 98-103. Cramer's title uses a phrase from mez, the Australian net artist (who writes in a hybrid of English language and pseudo-code), to make explicit his view that code can be taken as artistic material. It is both a filename for sourcecode that is executable (.exe) and a reference to cutup poetry such as in the work of William Burroughs (2003: 98), Cramer wishes to emphasise the point that code is not merely functional but can have expressive or poetic qualities too. Cramer provides many examples of poetic approaches to programming beyond the the merely functional approach: from perl poetry, code slang, 'viral scripting, in-code recursions and ironies (as, for example in the self-replicating source-code of "Quines", all of them being largely independent of particular transmission and storage media or output technology...' (2003 102). Code is clearly encoded and decoded - and some understanding of semiotics would suggest misunderstandings at the level of cultural difference. Cramer too wonders how code might be seen to be universal, and how language (as distinct from code) might be seen to be an international system. He draws upon Roland Barthes (in S/Z) in making the distinction between 'readerly' and writerly' texts and applying this to operating systems. Rather than the readerly properties of a GUI operating system that encourages consumption and hides the code, the command-line operating system of Unix is seen as writerly in terms of openness and encouraging the reader to become a producer of text or code. This is important for Cramer as it breaks down the false distinction between the writing and the tool with which the writing is produced, and in terms of the computer between code and data. It is almost as if GUI software disguises itself as hardware (Cramer, 2003: 101) using crude analogies like tools, desktops and trash cans - also see my notes on hardware for a very similar argument. On the other hand, the unix command line holds multiple possibilities for transformation and manipulation - combining instruction code and conventional written language for instance in poetic forms. Cramer cites the 1998 essay by Thomas Scoville 'The Elements of Style: UNIX as literature' in this connection (2003: 102) to insist on the writerly and literary aspects of programming. There has simply been too much emphasis on the visual and graphical aspects of creative computing in this regard. Good pedagogy here would require a backtrack on the fashion for visual literacy much against the grain of recent cultural policy-making (more essay-writing and hardcore programming, less traditional art and design perhaps). In keeping with post-structuralist thinking, for Cramer, computer language has become thoroughly entwined with subjectivity as we begin to think in these terms, using new codes (grammars and syntax). -- Erkki Huhtamo (2003), 'Web Stalker Seek Aaron: Reflections on Digital Arts, Codes and Coders' in Gerfried Stocker & Christine Schšpf, eds., Code - The Language of Our Time, Ars Electronica, Linz: Hatje Cantz, pp. 110-118. Erkki Huhtamo traces the artistic exploration of computer code to the early protagonists that had no alternative but to learn it, leading to an attention to the program itself rather than the output necessarily (2003: 111). Harold Cohen's Aaron is seen as a classic example of this tendency of someone developing a program over three decades to make art. Yet the code operates in a rather ambiguous relation to the overall artwork - it is decidedly part of Cohen's artistic output but more in terms of a representation of his skills and technique rather than an artwork as such. If anything, this is inconsistent with much conceptual art in the 1960s and the idea of the 'dematerialised art object (Lippard et al) that would emphasis process rather than end-product. Drawing upon Edward Shnaken's essay 'The House that Jack Built', Huhtamo cites Jack Burnham's 'Software' exhibition for the Jewish Museum in New York (1970) in this regard as part of a shift in the redefinition of what constitutes an arts practice in terms of both media and material, but also cites John Berger's Ways of Seeing (1972) as a way of connecting this to the acquisition of new forms of knowledge. For Burnham, the exhibition 'Software' encouraged an understanding of underlying structures in art and information systems in general. By drawing together practices in computer technology with conceptual art, 'Software' was to be seen as a linguistic metaphor for information exchange. Huhtamo is interested in what he calls 'software art purists' that emphasise the primacy of code as the main artistic material. To the media art historian, this is consistent with formalist experimentation with language and film to draw attention to the apparatus but also to the Greenbergian 'formalist' questions of a pure form outside of social context. He sees the software art movement as a continuation of this neo-modernist approach: 'emphasizing the centrality of the code and the algorithmic approach means positing a "hard core" often felt to be lost in the postmodern world'. In this connection we (Geoff Cox, Alex McLean, and Adrian Ward) are seen to 'fulfil many of the criteria for classical avant-garde movements' (2003: 117) - oh dear! - what Florian Cramer has elsewhere called 'software formalism'. Huhtamo simply paraphrases Cramer is making a false distinction between one 'group' (who aren't even a group) and another (mongrel) that emphasise the cultural and ideological underpinnings of computer programming that do not fit so easily in the 'modernist straitjacket' (2003: 117; note: he mentions postmodern techniques such as pastiche - one might like to point out the distinction that Jameson makes between pastiche and parody in this connection that would complicate the use of terms like postmodernism in the first place). Huhtamo gets lost here in the precise definition of 'formalist' concerns I think - what about a practice that is formalist in as much as it seeks to engage with the apparatus, and does so in order to engage with the mode of production and in turn the relations of production. Clearly this is not pure (nor simply free or open) but a decidedly dirty form of critical engagement appropriate to the task. [Note: Dirty code relates to this issue too, where a number of semiotic systems operate at the same time - for instance, in the work of nn or Jeff Instone - something not necessarily operable]. -- Christiane Paul (2003), 'Public CulturalProduction Art(Software){' in Gerfried Stocker & Christine Schšpf, eds., Code - The Language of Our Time, Ars Electronica, Linz: Hatje Cantz, pp. 129-135. For Paul, code operates at a conceptual level of understanding and this is why it is analogous to conceptual art practices that use formal instructions (2003: 129). She cites 'The Aesthetics of Generative Code' essay firstly to emphasise that code cannot be separated from an understanding of the overall structure it is part of. Whether this is art or not perhaps misses the point, it is cultural production and should be understood in those terms as both formal instruction and with cultural significance - both formalism and culturalism in other words. Like Huhtamo, she draws heavily on Florian Cramer's essay 'Concepts, Notations, Software, Art' and adopts his (un-dialectical) polarisation of a concern for a culturally-coded construct or subjective aesthetic expression. [note: although clearly people write code in different ways, see Kevin Marks & Maf Vosburgh, 'Code and Personality', http://homepage.mac.com/kevinmarks/personality.html - this is not the issue] No wonder the distinction is seen as unhelpful as it is falsity from the start. Even Paul, says such a distinction is hard to make and states: 'If software in general is not neutral but culturally encoded, there always is an interplay between formal and cultural aspects, which obviously varies depending on the emphasis of a specific project' (2003: 132). She takes the recommendation that 'a separation of code from the resultant actions would result in a limitation of the aesthetic experience' (quote us, paraphrased 2003; 133). Although seeing the attention of the 'backend' as fringe, she takes the risk of including the source code alongside the exhibited work in CODeDOC at the Whitney Museum in 2003 (see Cramer's criticism of this in Read_Me Reader). This approach is perhaps best exemplified in artwork that is a data visualisation where the execution and process are evident but only in a meaningful way if the larger context or system is revealed. There is some danger of the aestheticisation of code - analogous to the concerns of Benjamin in calling for a politics of aesthetics rather than an aesthetics of politics (in his artwork essay; note: this distinction can similarly be applied to the undialectical separation of aesthetic concerns over cultural ones. Clearly and in unashamedly modernist terms, both/and are preferred over either/or as Marshall Berman would put it). -- Alan Sondheim (2004), 'Notes on Codework', nettime, February 11. In a similar way, 'Codework' gives a political dimension to a phrase like code-poetry to production (and labour). Sondheim states rather obliquely: 'Every more or less traditional text is codework with invisible residue; every computer harbours the machinic, the ideology of capital in the construction of its components, the oppression of underdevelopment in its reliance on cheap labor.' [I think he means what Marx would call dead labour]. And furthermore, as generative code, it has partly produced its own work. -- notes on slub and live coding: These issues of emphasising process over (recorded) end-product are evident in some experimental music that employs live coding (Collins et al, 2004). For instance, 'slub' (Alex McLean & Adrian Ward) use real-time scripting during live laptop performances in the spirit of improvisation. In this approach, third party graphical interfaces and programming languages are seen as too limited and prescriptive. Instead interpreted scripting languages (such as perl) are seen to hold more open-ended creative possibilities and perhaps more in keeping with the expressive qualities of the musician using an instrument. Live coding is perhaps more analogous to the scratching of contemporary Djs and holds some of the real-time, performative fascination as well as some formal similarities (such as two laptops instead of decks - without falling into literalism). With live coding of course the two laptops can process data collaboratively somewhat breaking the individualist trajectory of much conventional improvisation techniques (think of the jazz solo or dexterous DJ). Also, significantly, the desktops of both machines are usually projected allowing for some understanding of the process (according to programming literacy) and against the grain of the spectacle of VJ culture. In this, any improvisation relies on a predictive understanding of complex and generative systems. There is some risk involved 'in that many think they are trying to deprecate the creative role of the performer. On the contrary, slub is opening up the determinate processes of a computer in order to generate music' (Collins etal, 2003: 326), glitches and all. Sometimes it sound good too.