Why has software code become an object of intense interest in several different domains of cultural life? In art (.net art or software art), in Open source software (Linux, Perl, Apache, et cetera (Moody; Himanen)), in tactical media actions (hacking of WEF Melbourne and Nike websites), and more generally, in the significance attributed to coding as work at the pinnacle of contemporary production of information (Negri and Hardt 298), code itself has somehow recently become significant, at least for some subcultures. Why has that happened? At one level, we could say that this happened because informatic interaction (websites, email, chat, online gaming, ecommerce, etc) has become mainstream to media production, organisational practice and indeed, quotidian life in developed and developing countries. As information production moves into the mainstream, working against mainstream control of flows of information means going upstream. For artists, tactical media groups and hackers, code seems to provide a way to, so to speak, reach over the shoulder of mainstream media channels and contest their control of information flows.1 A basic question is: does it?
What code does
We all see content flowing through the networks. Yet the expressive traits of the flows themselves are harder to grapple with, partly because they are largely infrastructural. When media and cultural theory discuss information-network society, cyberculture or new media, questions of flow specificity are usually downplayed in favour of high-level engagement with information as content. Arguably, the heightened attention to code attests to an increasing awareness that power relations are embedded in the generation and control of flow rather than just the meanings or contents that might be transported by flow.
By definition, flow is something continuous. In the case of information, what flows are not things but patterns which can be rendered perceptible in different ways—as image, text, sound—on screen, display, and speaker. While the patterns become perceptible in a range of different spatio-temporal modes, their circulation is serialised. They are, as we know, composed of sequences of modulations (bits). Loops control the flow of patterns. Lev Manovich writes: programming involves altering the linear flow of data through control structures, such as 'if/then' and 'repeat/while'; the loop is the most elementary of these control structures (Manovich 189). Drawing on these constructs, programming or coding work gain traction in flows.
Loops also generate flows by multiplying events. The most obvious example of how code loops generate and control flows comes from the graphic user interfaces (GUIs) provided by typical operating systems such as Windows, MacOs or one of the Linux desktop environments. These operating systems configure the visual space of millions of desktop screen according to heavily branded designs. Basically they all divide the screen into different framing areas—panels, dividing lines, toolbars, frames, windows—and then populate those areas with controls and indicators—buttons, icons, checkboxes, dropdown lists, menus, popup menus. Framing areas hold content—text, tables, images, video. Controls, usually clustered around the edge of the frame, transform the content displayed in the framed areas in many different ways. Visual controls are themselves hooked up via code to physical input devices such as keyboard, mouse, joystick, buttons and trackpad. The highly habituated and embodied experience of interacting with contemporary GUIs consists of moving in and out, within and between different framing areas, using visual controls that respond either to pointing (with the mouse) or keyboard command to change what is displayed, how it is displayed or indeed to move that content elsewhere (onto disk, across a network).
Beneath the highly organised visual space of the GUI, lie hundreds if not thousands of loops. The work of coding these interfaces involves making loops, splicing loops together, and nesting loops within loops. At base, the so-called event loop means that the GUI in principle stands ready at any time to accept input from the physical interface devices. Depending on what that input is, it may translate into direct changes within the framed areas (for instance, keystrokes appear in a text field as letters) or changes affecting the controls (for instance, Control-Enter might signal send the text as an email). What we usually understand by interactivity stems from the way that a loop constantly accepts signals from the physical inputs, queues the signals as events, and deals with them one by one as discrete changes in what appears on screen. Within the GUI's basic event loop, many other loops are constantly starting and finishing. They are nested and unnested. They often affect some or other of the dozens of processes running at any one time within the operating system. Sometimes a command coming from the keyboard or a signal arriving from some other peripheral interface (the network interface card, the printer, a scanner, etc) will trigger the execution of a new process, itself composed of manifold loops. Hence loops often transiently interact with each other during execution of code.
At base, the GUI shows something important, something that extends well beyond the domain of the GUI per se: the event loop generates and controls informations flows at the same time. People type on keyboards or manipulate game controllers. A single keypress or mouse click itself hardly constitutes a flow. Yet the event loop can amplify it into a cascade of thousands of events because it sets other loops in process. What we call information flow springs from the multiplicatory effect of loops.
A typology of looping
Information flows don't come from nowhere. They always go somewhere. Perhaps we could generalise a little from the mundane example of the GUI and say that the generation and control of information flows through loops is itself regulated by bounding conditions. A bounding condition determines the number of times and the sequence of operations carried out by a loop. They often come from outside the machine (interfaces of many different kinds) and from within it (other processes running at the same time, dependent on the operating system architecture and the hardware platform). Their regulatory role suggests the possibility of classifying loops according to boundary conditions.4 The following table classifies loops based on bounding conditions:
|Type of loop||Bounding condition||Typical location|
|Simple & indefinite||No bounding conditions||Event loops in GUIs, servers ...|
|Simple & definite||Bounding conditions determined by a finite set of elements||Counting, sorting, input and output|
|Nested & definite||Multiple bounding conditions||Transforming grid and table structures|
|Recursive||Depth of possible recursion (memory or time)||Searching and sorting of tree or network structures|
|Result controlled||Loop ends when some goal has been reached||Goal-seeking algorithms|
Interactive and indefinite
|Bounding conditions change during the course of the loop||User interfaces or interaction|
Although it risks simplifying something that is quite intricate in any actually executing process, this classification does stress that the distinguishing feature of loops may well be their bounding conditions. In practical terms, within program code, a bounding condition takes the form of some test carried out before, during or after each iteration of a loop. The bounding conditions for some loops relate to data that the code expects to come from other places—across networks, from the user interface, or some other devices. For other loops, the bounding conditions continually emerge in the course of the loop itself—the result of a calculation, finding some result in the course of searching a collection or receiving some new input in a flow of data from an interface or network connection.
Based on the classification, we could suggest that loops not only generate flows, but they generate those flows within particular spatio-temporal manifolds. Put less abstractly, if we accept that flows don't come from nowhere, we then need to say what kind of places they do come from. The classification shows that they do not come from homogeneous spaces. In fact they relate to different topologies, to the hugely diverse orderings of signs and gestures within mediatic cultures. To take a mundane example, why has the table become such an important element in the HTML coding of webpages? Clearly tables provide an easy way to organise a page. Tables as classifying and visual ordering devices are nothing new. Along with lists, they have been used for centuries. However, the table as onscreen spatial entity also maps very directly onto a nested loop: the inner loop generates the horizontal row contents; the outer loop places the output of the inner loop in vertical order. As web-designers quickly discovered during the 1990s, HTML tables are rendered quickly by browsers and can easily position different contents—images, headings, text, lines, spaces—in proximity. In shorts, nested loops can quickly turn a table into a serial flow or quickly render a table out of a serial flow.
We started with the observation that artists, writers, hackers and media activists are working with code in order to reposition themselves in relation to information flows. Through technical elements such as loops, they reappropriate certain facets of the production of information and communication. Working with these and other elements, they look for different points of entry into the flows, attempting to move upstream of the heavily capitalised sites of mainstream production such as the Windows GUI, eCommerce websites or blockbuster game titles. The proliferation of information objects in music, in visual culture, in database and net-centred forms of interactivity ranging from computer games to chat protocols, suggests that the coding work can trigger powerful shifts in the cultures of circulation. Analysis of loops also suggests that the notion of data or information flow, understood as the continuous gliding of bits through systems of communication, needs revision. Rather than code simply controlling flow, code generates flows as well.
What might warrant further thought is just how different kinds of bounding conditions generate different spatio-temporal patterns and modes of inclusion within flows. The diversity of loops within information objects imply a variety of topologically complicated places. It would be possible to work through the classification describing how each kind of loop maps into different spatial and temporal orderings. In particular, we might want to focus on how more complicated loops—result controlled, recursive, or interactive and indefinite types—map out more topologically complicated spaces and times. For my purposes, the important point is that bounding conditions not only regulate loops, they bring different kinds of spatio-temporal manifold into the seriality of flow. They imprint spatial and temporal ordering. Here the operationality of code begins to display a generative dimension that goes well beyond merely transporting or communicating content.
1. At a more theoretical level, for a decade or so fairly abstract notions of virtuality have dominated media and cultural studies approaches to new media. While that domination has been increasingly contested by more fine grained studies of how the Internet is enmeshed with different places (Miller and Slater), attention to code is justified on the grounds that it constitutes an increasingly important form of expression within information flows.
2. Detailed discussion of these looping constructs can be found in any programming textbook or introductory computer science course, so I will not be going through them in any detail.
3. For instance, the cycles of the clock chip are absolutely irreducible. Virtually all programs implicitly rely on a clock chip to regulate execution of their instructions.
4. A classification can act as a symptomatology, that is, as something that sets out the various signs of the existence of a particular condition (Deleuze 368), in this case, the operationality of code.