3. David Berry (Philosophy of Software) argues that there is a materiality to code, which forms the basis for what he sees as a phenomenology of code. In what sense does he think that code is, or can be, material, and does his analysis make sense in the thinking of some other writers on your third list? In particular, how does this line up with the (post-) structural approach to code that we might see in the early Derrida or (arguably) in Floridi? Much contemporary theory of code suggests that materiality is just code (a la The Matrix) in a sophisticated form. Does Berry essentially reject that current of thought, or does he extend it, or something else?

A position in popular culture that is supported by much contemporary theory suggests that materiality is just code in a sophisticated form, as in the 1999 movie The Matrix, in which most of humanity go through life experiencing totalizing, immersive virtual reality simulations while their bodies are suspended in nutrients and farmed by the machines for their electricity.

TG: Another possible example in the B-grade film Species: the monstrous other that arrives from outer space isn’t an organism but a code; once sequenced the horror begins.

N. Katherine Hayles argues that the extreme position, which she dubs the Computational Universe and the Regime of Computation, while it does have its vocal advocates in Wolfram, Fredkin, Morowitz, and Kurzweil, does not need to be fully endorsed in order to act and believe as if everything was inherently programmed and governed by code. Note that even in the movie, there is a material world beyond the mass hallucination generated by code.

BJ: True, there is, but that’s what also makes the movie a modernist narrative. In other words, there’s a point at which we know the truth. What if that “material” world was itself another layer of illusion? What if Morpheus was wrong, that the “farms” were not for producing power, but were wetware running the code itself? Anyway, that’s not really germane to your argument here.

Rather, we are living in an age where the ontological status of the Regime of Computation remains undecided, but has real effects nonetheless (My Mother was a Computer 17-29). How then do we humans creatively proceed, and not collapse into the despair of paranoid androids and other unhappy artificial intelligences? Dissemination of a philosophy of computing or programming has yet to occur; therefore, similarly named texts like David Berry's Philosophy of Software, Luciano Floridi's Philosophy and Computing, and Kumiki Tanaka-Ishii's Semiotics of Programming constitute a default query space. Berry in particular argues that there is a materiality to code, which forms the basis for a phenomenology of computation, while intentionally casting aside the stock computationalist questions, namely, whether the human mind and the material universe as a whole are ultimately computers. After summarizing his position, I will investigate how it stacks up against these other contemporary theorists, as well as what may be considered a “legacy” poststructuralist approach to code based on Derrida's “Plato's Pharmacy” in Dissemination.

BJ: A tactful way of saying “passé”.

Derrida can be read using Kittler method, latching onto his telephone call, Macintosh, and Freudian archive, despite his default legacy characterization as a traditional humanities theorist who does not program; in fact, the parasite ethic Berry reaches is wholly consistent with the Derridean approach deployed by Landow. Ulmer is on the other side, at least as a heavy technology adopter, although also not a literal computer programmer.

David Berry's Philosophy of Software explicitly and implicitly argues for the materiality of code. First, in his definition of code as “the textual and social practices of source code writing, testing and distribution,” which he distinguishes from software, the “the processual operating form,” particularly commercial applications (31-32), he is careful to implicate not just the symbolic, textual artifacts but the social and cultural activities in which it is used and continually transformed. It could be argued that he really means is that all code is situated, embodied in a milieu, but source code itself as text is immaterial. However, Berry appeals to its materiality repeatedly. Code is spun like an enormous web by countless man-hours of work, “invisibly around us, organizing, controlling, monitoring and processing” (3). Code is “entangled with all aspects of our lives” (6). It can only be understood “by actually reading the code itself and watching how it operates,” implying a phenomenal, if not a material presence (10). Indeed, the aim of his phenomenological approach is “to bring to the fore how code is computational logic located within material devices,” and chapter 3 is devoted to looking “at some concrete examples of the materiality of code and how we can understand it as both written, read and executed” (63). He employs Bruno Latour's 'trial of strength' in the context of professional software development practices to demonstrate “the materiality and obduracy of code” in prototyping, test cases, documenting, and so on, noting that “each step creates physical entities (e.g. documentation) and tests that further reinforce the materiality of code” (65-67). His most compelling application of the term comes in the discussion of actual code, from the study of the leaked Microsoft code and climate research code, to the social contests of writing underhanded, obscure, and obfuscated, code which “demonstrates both the materiality of source code itself, and the fact that unreadable source code can still be executable” (81). The latter examples parallel the materiality of other textual forms made evident by visual poetry and artists books (Hayles). In the second half of Philosophy of Software, in which Berry develops his phenomenology of computation, he also develops a theory of subjectivity based on computational comportment, or “how to know one's way around computationally with respect to things in the world” because “technical devices are delegated performative and normative capabilities which they prescribe back onto humans and non-humans” (121-123). His phenomenological analysis of technical devices and theory of subjectivity both appeal to the unescapable physical dimension of computation as it is embodied in devices and digital media making up the built environment in which humans live. The outcome is a “restructuring of a post-human subjectivity that rides on top of a network of computationally-based technical devices,” for which the exemplar is the experience of the hard core programmer who dreams in code, “where thinking in terms of computational processes, as processual streams, is the everyday experience of the programmer, and concordantly, is inscribed on the programmer's mind and body” (145-149). The coupling between code, program, technical devices, humans, and world seems permeated by materiality.

From this quick survey of the text where materiality and code are explicitly linked, I want to examine some points in detail, as well as compare them to the positions of other theorists. Berry suggests that “the ontology of code is specifiable, indeed, programmers already know what code is, qua code” (43). It is not an explicitly stated ontology, except when it comes to the vocabulary of microprocessors, but nonetheless concretizes around habituation, structural constraints of languages and tools, and shared knowledge and practices. If these are not material conditions, in the sense of Marxist production, then they are at least exquisitely situated.

BJ: It might be necessary to clarify what “materiality” actually means for Berry. You identify two possibilities here, Marxian materialism and situatedness. You sketch out in the previous paragraph a version of materiality that comes close to the raw material of artistic production, as well as “computational logic located within material devices”. It’s not that you don’t have a sense of materiality here, it’s that there are quite a few senses. And, I can imagine other senses that might not fit code. So, with all these senses, can we come up with a sense of what it means in this context?

Galloway fills in some of the ambiguity of what is meant by materiality, although his aesthetic (phenomenological?), Marxist vitalist interpretation seems to consume an unnecessarily large number of pages to argue for Foucauldian biopower materialism exemplified by the Interface Message Processors with whose software evolved the early internet that would one day become the wetware of the Matrix. I look at pinball machines as more advanced mechanisms than the early theorists extol.

Thus code exists within contexts, historical and practical contexts in the case of organized software developed, in a way that can be compared to other textual entities such as literary writings. Consider the discussion of the word pharmakon in “Plato's Pharmacy” in Dissemination. One of Derrida's objectives is to dispel the assumption that the Saussurian law of the arbitrariness of signs within languages is the norm. The pharmakon itself must be wrested out of culture, in the broad sense of phemonena, myth, and scientific object, in order to be deployed as logos, philosopheme. He makes multiple appeals to the structural constraints of the overall historical and linguistic context, such that:

The word pharmakon is caught in a chain of significations. The play of that chain seems systematic. But the system here is not, simply, that of the intentions of an author who goes by the name of Plato. The system is not primarily that of what someone meant-to-say {un vouloir-dire}. Finely regulated communications are established, through the play of language, among diverse functions of the word and, within it, among diverse strata or regions of culture. (95)

He goes into great detail to explain why pharmakos never appears in the Platonic corpus, although numerous other forms of the word do. He could as well be arguing why a particular version of a common C library function is never used in a particular software application. Moreover, Derrida demonstrates how translation cancels out productive resources of ambiguity and context, noting that “its translation by 'remedy' nonetheless erases, in going outside the Greek language, the other pole reserved in the word pharmakon. It cancels out the resources of ambiguity and makes more difficult, if not impossible, an understanding of the context” (97). Likewise, a snippet of code taken out of the context of its milieu is akin to a translation, for it is no longer connected to the system whose structural constraints form part of its sense.

RM: This is an interesting line of thinking to pursue further, I think. For example, the whole idea of deprecated code, or code that continues to exist in a library despite the wishes of the language authors, and why that occurs. (Because the deprecated feature is so handy? Or easier to use? Or the programmer just doesn’t want to adapt and learn the newer way of thinking? ) I wonder where this comparison begins to break down. For example, code taken out of context has not only the potential to be misinterpreted, but to break down entirely due to lack of dependencies or other necessary infrastructures (SW or HW).

Berry makes a similar argument about the difficulty of reading the leaked Microsoft source code. While it does serve as a window into the daily Microsoft build process and reveal the extent to which Microsoft programmers performed inelegant hacks, “many of the commentators remarked on the unlikely situation of anyone finding much of interest to take from Microsoft code, pointing to the difference between having the source code as a textual repository and actually getting it to compile” (71).

This evidence of the materiality of code could be construed instead as evidence of the situatedness of code, if it were not for other theorists who argue more forcefully than Berry for the materiality of code. It is worth remembering that the earliest electronic computers were hard wired, the concept of code arose with the stored program architecture articulated by Burks, Goldstine, and von Neumann in their 1946 report “Preliminary Discussion of the Logical Design of an Electronic Computing Instrument.” The bulk of this document concerns the theory and design of the arithmetic unit that performed basic mathematical operations via binary arithmetic, of which they write, “The operations that the machine will view as elementary are clearly those which are wired into the machine. . . . In general, the inner economy of the arithmetic unit is determined by a compromise between the desire for speed of operation – a non-elementary operation will generally take a long time to perform since it is constituted of a series of orders given by the Control – and the desire for simplicity, or cheapness, of the machine” (1). Thus the arithmetic operations themselves had to be built into the circuitry, along with the memory, control and input/output mechanisms, before any stored programs could be written, debugged, and run; when they did run, those programs were intimately connected to the physical circuits built to perform those basic operations, initially with the limited capacity of “4,000 numbers of 40 binary digits each” (2). Friedrich Kittler's essay “There is no Software” makes the claim that “only in Turing's paper On Computable Numbers with an Application to the Entscheidungsproblem does there exist a machine with unbounded resources in space and time, with an infinite supply of raw paper and no constraints on computation speed. All physically feasible machines, in contrast, are limited by these parameters in their very code” (152). The basic code operations are burned into silicon, and it is through a long chain of layered operations that interpreters, compilers, and assemblers transform textual source code into machine code. Thus actual, working code is always limited by hardware, and therefore, fundamentally material.

RM: And even Turing’s theoretical conception of the Turing Machine is still somewhat bounded by metaphor and even technology in some sense, right? As in, we need to understand the concept of a “tape” that can be extended and “written to” and “read from.”

Belief in the immateriality of code is prevalent because “the so-called philosophy of the so-called computer community tends systematically to obscure the hardware with software, electronic signifiers with interfaces between formal and everyday languages” (152). The recently inaugurated digital humanities field of platform studies intentionally foregrounds the materiality of computer platforms. In Racing the Beam, Nick Montfort and Ian Bogost describe the rigors of coding for the Atari VCS:

Instead [leveraging functionalities encapsulated in an automated external apparatus], the VCS programmer must draw each frame of a program's display manually to the screen, synchronizing the 6507 processor instructions to the television's electron gun via the TIA [Television Interface Adapter]. . . . In these cases, the programmer must carefully “cycle count” processor instructions so they execute at the right time. While “racing the beam” is a catchier name, “pacing the beam” is more apt, since the program might have to be sped up or slowed down. . . . Next comes the overscan period. At the time the Atari VCS was designed, the position of the CRT in the television casing varied considerably. The overscan period is a “safe zone” to account for this, and it provides the programmer with another thirty scan lines of time to run program logic. (28-30)

Writing such a program on paper, and getting it right, is virtually impossible, even with a detailed knowledge of the hardware schematics. A great deal of trial and error running it on the VCS hardware is required to correctly pace the beam. It is not surprising that the platform approach to the phenomenology of computation gets its inspiration from real-time applications like the VCS, where what Wendy Hui Kyong Chun calls the vicissitudes of execution are paramount. The basic argument of “On 'Sourcery,' or Code as Fetish” is that we fail to comprehend the relationship between source code and its execution context, believing that source code is automatically executable, rather than subject to a series of nontrivial compilation and interpretation processes. “To make the argument that code is automatically executable, the process of execution itself must not only be erased, but source code also must be conflated with its executable version” (305). Chun reaches beyond the act of authoring source code to involve the other actors involved in software production, both human and machine, which further establishes the materiality of code by embedding it in the cultural scene and the built environment. Martin Campbell-Kelly's book From Airline Reservations to Sonic The Hedgehog: A History of the Software Industry does an excellent job widening the scope of what really goes on in software development beyond the act of creating new source code, reminding us that marketing campaigns, distribution, documentation, training, and support form part of the materiality of code.

RM: This is virtually oozing T&T goodness at this point! Transition a little awkward here. In fact, this whole sentence is a little strange.

It is time to engage Luciano Floridi's Philosophy and Computing and Kumiko Tanaka-Ishii's Semiotics of Programming, the other texts whose titles form with Berry's Philosophy of Software a discourse network standing in for the missing “philosophy of computing” and “philosophy of programming” to which this discussion of the materiality of code belongs. For the views of these theorists also make what I feel are the strongest objections to the arguments given so far in favor of the materiality of code. Floridi casts code, computation, and programming in the context of the logical proofs involving Universal Turing machines (UTM). His elaboration of Turing's theorem informs his take on code: “to say that a UTM is a TM that can encompass any other TM is like saying that, given m specific flow charts, drawn in a standard and regimented symbolism, which describe the execution of as many specific tasks, there is a universal flow chart n, written with the same symbols, that can reproduce any of them and thus perform the same tasks” (29). Combined with his insistence that algorithms are “explicit and non-ambiguous; faultless and infallible; finite; deterministic and sequential” (47-48), then source code is able to circulate freely within the immateriality of the UTM (or sufficiently outfitted Von Neumann Machine, VNM) as Boolean logic. The pains Floridi goes through over 20 pages with quasi-mathematical proofs to arrive at the VNM from the basic TM operation seem to provide an immaterial plane for code to exist without reference to any materiality. The vicissitudes of execution and specificity of platforms collapse into the distinction he makes between architectures and hardware implementations: “The same architecture can have different hardware implementations. . . . On the other hand, since each type of CPU recognizes a certain set of instructions, if two microprocessors implement different ISA [information structure architecture] then their software will not be compatible. This is why we cannot use software written for a Macintosh with an IBM-compatible and vice versa, although both are VNMs” (55).

RM: Right, but why is this so? For example, this is really up to the hardware designers to choose which instruction sets their hardware will support, right? So is this rhetorically/politically/economically motivated, or is there indeed something inherent to the hardware, independent of human authorship and design, that influences how these machines are developed from theory to practice? Maybe instead of “contribute to general semiotics” a more accurate description might be “broaden our understanding of semiotics”

A parallel development can be found in the Semiotics of Programming, which aims to contribute to general semiotics by looking at how traditional problems from linguistics are handled in programming languages. As Floridi does through proofs with Turing Machines, Tanaka-Ishii employs lambda calculus to arrive at some general conclusions about computability, particularly concerning reflexivity. By working through her examples in parallel languages, Haskell and Java, without reference to any platform, the question of materiality seems negligible, and differences between computers and humans are highlighted instead. With a nod toward Chun's sourcery arguments, Tanaka-Ishii does dwell on the issue of side effects, “a situation in which the value of a variable is unexpectedly changed, despite the programmer's intentions, during evaluation of an expression. . . . Side effects include exception handling, nondeterminacy, concurrency, and, above all, interaction” (164). However, the context of this discussion is how to avoid unintended changes in signs, hearkening back to Saussure (and Derrida), for whom the arbitrariness of linguistic signs are nonetheless bound. “This condition of globalness serves to restrain easy value changes and as a consequence natural language values are relatively fixed. . . . In contrast, in the case of computer signs, change easily occurs, since a computer language system does not have any restrictions corresponding to the social conventions that stabilize sign values” (162). In this case, it is the vicissitudes of execution rather than the materiality or immateriality of code that makes computer languages susceptible to unexpected changes.

BJ: Floridi and Tanaka-Ishii in relation to materiality and code.

RM: This is a satisfying way of wrapping up your essay and returning to your original thoughts and the original question prompt.

Returning to Berry, I think it is clear that he would consider the examples given by Floridi and Tanaka-Ishii to be special cases in which specially selected code is intentionally chosen so that it can be presented in a context-free manner in order to demonstrate logical or semiotic relations without regard to its place within the overall operating environment. This perspective, he may argue, emphasizes the specific, structural properties expressed in the code as a self-contained unit; however, “we should not underestimate the ability of technology to act not only as a force, but also as a 'platform'. This is the way in which the loose couplings of technologies can be combined, or made concrete (Simondon 1980), such that the technologies, or constellation of technologies act as an environment that we hardly pause to think about” (119). On the one hand, this “force factor” is the discernable, “face value” of code, exactly what is highlighted in a context-free, immaterial presentation. The force of an algorithm can be studied as a dissociated, textbook example. On the other hand, how code functions in the loose couplings of layered systems, in which a single algorithm, class function, or even a single million-line application that is just one of thousands interoperating among each other and with other devices, and humans, is the “platform” sense, and that is always embedded in specific materialities. Note this perspective is not equivalent to assuming everything is code, or that the mind can be characterized as code, and Berry avoids both positions (11-13). What it does mean is that phenomenologically, “this 'everyday computational' is a comportment towards the world that takes as its subject-matter everyday objects which it can transform through calculation and processing interventions,” pointing towards the aforementioned post-human subjectivity riding on top of networks of technical devices. Cast in this manner, snippets of code constituting such streams might be like individual cells of a living organism seen with a microscope, producing the illusion that they are individually floating in space rather than a tiny part of an enormous assemblage. If this is what is meant by distinguishing the immateriality and the materiality of code, then Berry has done a thorough job arguing for making it matter.

BJ: Summarizing Berry, making the argument for materiality, and considering the alternatives. And, although it isn’t mentioned here, it’s a Deleuzian-style answer to Deleuze.

Works Cited

Aspray, William and Arthur Banks, eds. Papers of John von Neumann on Computing and Computer Theory in Charles Babbage Institute Reprint Series for the History of Computing, vol. 12. Cambridge, MA: The MIT Press, 1987.

Berry, David M. The Philosophy of Software: Code and Mediation in the Digital Age. Basingstoke, Hampshire: Palgrave Macmillan, 2011. Print.

Bogost, Ian. Alien Phenomenology: or What It's Like to Be a Thing. Minneapolis: University of Minnesota Press, 2012. Print.

Campbell-Kelly, Martin. From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry. Cambridge, Mass: MIT Press, 2003. Print.

Chun, Wendy Hui Kyong. "On 'Sourcery,' Or Code As Fetish." Configurations: A Journal Of Literature, Science, And Technology 16.3 (2008): 299-324. MLA International Bibliography. Web. 12 Dec. 2012.

Derrida, Jacques. Dissemination. Chicago: University Press, 1981. Print.

Floridi, Luciano. Philosophy and Computing: An Introduction. London: Routledge, 1999. Print.

Kittler, Friedrich A., John Harvey Johnston, and John Johnston. Literature, Media, Information Systems : Essays / Friedrich A. Kittler ; Edited And Introduced, John Johnston. n.p.: Amsterdam : G+B Arts International, 1997. Print.

Montfort, Nick, and Ian Bogost. Racing the Beam: The Atari Video Computer System. Cambridge, Mass: MIT Press, 2009. Print.

Tanaka-Ishii, Kumiko. Semiotics Of Programming. New York, NY US: Cambridge University Press, 2010. PsycINFO. Web. 10 Dec. 2012.