The World of Computationality: Flickering Objects and Streaming-beings

Accepting that the Worldhood of the World allows us to encounter anything at all (Heidegger 1977). What would be the structural features of a world of computationality understood as an alternative mode of revealing in contrast to the challenging-forth of technicity? For Heidegger electricity was the paradigmatic metaphor for technicity, both in terms of its generation through the challenging-forth of nature, through coal, oil, hydropower, etc. and in terms of the switching systems that were required to route both production, distribution and consumption of the electricity itself. He saw this switiching capacity as a process of ordering by ‘ordering beings’ where:

Everywhere everything is ordered to standby, to be immediately on hand, indeed, to stand there just so that it may be on call for a further ordering (Heidegger 1977).

Here I want to suggest that technicity isn’t sufficient to describe the contemporary mode of revealing through computationality. Indeed, challenging forth is better understood, as indeed Heidegger concedes, as a modern technology, and indeed I would argue not necessarily applicable to the kinds of postmodern technologies, such as the computer, that increasingly permeate our everyday life. In computationality, then, the paradigmatic metaphor I want to use is real-time streaming technologies and the data flows, processual stream-based engines and media interfaces that embody them. This is to stop thinking about the digital as something static and object-like and instead consider its 'trajectories'. Here I am thinking about the way in which scripts function to create loops and branching, albeit highly complex forms, and create a stable 'representation', which we often think of as an digital 'object'. Under the screen surface, however, there is a constant stream of processing, a movement and trajectory, a series of lines that are being followed and computed. Something like Twitter suggests the kind of real-time experiential technology that I am thinking about and the difficulty of studying something unfolding in this manner, let alone archiving or researching, without an eye on its processual nature encourages serious category errors.[1] The aim of this article is to begin to develop some of the ideas outlined in The Philosophy of Software through a phenomenology of computation (Berry 2011). In the following table, for example, I want to explore how we might think about this different mode of existence of a highly softwarized streaming ontology. 

	Technicity (modern technology)	Computationality (postmodern technology)
Mode of Revealing	Challenging-forth (Gestell)	Streaming-forth
Paradigmatic Equipment	Technical devices, machines.	Computational devices, computers, processors.
Goals (projects)	1. Unlocking, transforming, storing, distributing, and switching about Standing Reserve (Bestand). 2. Efficiency.	1. Trajectories,  Processing information, Algorithmic transformation (aggregation, reduction, calculation), as data reserve. 2. Computability.
Identities (roles)	Ordering-beings	Streaming-beings
Paradigmatic Epistemology	Engineer, Time-motion studies, Methods-Time Measurement (MTM), instrumental rationality	Design, Information theory, graph theory,  data visualisation, communicative rationality

Within Gestell every subject/object is a story of challenging-forth. This is related to a structural map, or ground-plan, which describes a priori what the essences of particular beings are, however this is not innate, rather drawn from the grounding of intelligibility. As Heidegger explains:

As a destining, it banishes man into that kind of revealing that is an ordering. Where this ordering holds sway, it drives out every other possibility of revealing (Heidegger 1977).

Thus challenging-forth turns everything into resources, creating a world of objects and equipment on standby ready to be used in larger aggregates. For Heidegger there is a totalizing character of challenging-forth which forces it to attempt to apply the principle of efficiency to other marginal practices, and hence with it the danger of becoming the last possible mode of revealing.

The coming to presence of technology threatens revealing, threatens it within the possibility that all revealing will be consumed in ordering and that everything will present itself only in the unconcealedness of standing reserve (Heidegger 1977). 

In contrast, I want to suggest that computationality is distinct from challenging-forth as technicity, inasmuch as it is a streaming-forth. One aspect of this is that streaming-forth generates second-order information and data from the world which is itself seen increasingly as flow. This collected information is then subject to further processing and algorithmic transformation, feedback thus becomes part of the ecology of computationality. Additionally, computational devices not only withdraw – indeed mechanical devices such as car engines clearly also withdraw – rather that computational devices both withdraw and are constantly pressing to be present-at-hand in alternation. They are in a curious middle state, this I call ‘unready-to-hand’ drawing on Heidegger's notion of conspicuousness. Breakdowns, such as these, serve an extremely important cognitive function revealing to us the nature of our practices and equipment by bringing them ‘present-at-hand’ to our attention. However, the present-at-hand in computationality is of extremely limited duration, but also repeated in random ways, we could think of this as a stream of unreadiness-to-hand, specific to this mode of revealing. It is only when a breakdown occurs that we become aware of the fact that ‘things’ in our world exist not as the result of individual acts of cognition but through out active participation in a domain of discourse and mutual concern. We can think of this specific computational breakdown in two different ways:

1. Something intrinsic to the computational means that computational devices (and entities that contain computational devices) are constantly moving in and out of this unready-to-hand state. 
2. Perhaps due to the loose coupling between interface and underlying code, this causes the pseudo-state of unreadyness-to-hand. 

Anyway, it is clear from the history of computing that computers do not, nor have ever, been able to run themselves. They are constantly suffering from breakdowns, bugs, errors and crashes. Well-engineered physical machines do not suffer this constant breakdown. You could think of it as an oscillation, perhaps due to the underlying fragility of the nature of code, that means it is always on the constant verge of breakdown (again car engines do not act like this, once they are working they are working, generally speaking). Software and code is thus always calling to us from a position of unreadiness-to-hand. Software programmers have a lovely term for what I am getting at when they say that code throws an exception, which causes the machine to pause and wait for further instruction or execute an alternative method, or if no such instruction is available or forthcoming, it is said that code is unable to catch the exception and it crashes in someway (sometimes gracefully and at other times catastrophically). 

Therefore it is not that computational equipment is different from equipment in other modes of revealing. Nor that there are special forms of computational equipment that have a ‘third mode' or somehow stand middle between presence and absence. Rather, computational devices appear to have the rather novel feature/bug of oscillating rapidly between Vorhandenheit/Zuhandenheit. Or perhaps better, constantly becoming ready-to-hand/unready-to-hand in quick alternation. And by quick this can be happening in microseconds, milliseconds, or seconds, repeatedly in quick succession. This aspect of breakdown has been acknowledged as an issue within human-computer design and is seen as one of pressing concern to be ‘fixed’ or made invisible to the computational device user (Winograd and Flores 1987). Although in previous accounts attention has not been paid to the rapidity of the oscillations that I am drawing attention to here. 

Hence within computationality absence and presence are being experienced in this very specific and very curious way enabled by computational devices. This quantitative micro/milli/second oscillations between modes translate into an odd mediated pseudo-mode which is, perhaps, qualitatively experienced as 'uncanny' and which might analytically be referred to as 'radically unready-to-hand' or ‘flickering objects'.[2] This is part of the specificity of the phenomenological experience that I am gesturing towards in computationality as a mode of revealing in contrast to technicity.

We used to think that this feature/bug of computational systems was due to the immaturity of the disciplines and methods, but after 40 years of writing code/software we still suffer from the same problems (indeed called the software crisis in the 1960s). Code is now bigger than a single human being can understand. Thus, in a running system, and in escaping our comprehension, it inevitably has aporia and liminal areas that mean we cannot truly control or even understand its operation. 

We might expect that the kinds of things that show up as equipment, goals, and identities would be specific to computationality. Firstly, the equipment would be more autonomous of human control and have delegated agency within its software/code structures. This might mean that in a similar way to the principle of physis which governed the Greek world, things might ‘whoosh’ up unexpectedly in a manner which was a bursting bringing-forth (Dreyfus 2004). Of course, in this sense they are computationally bringing themselves forth with hidden potential, but the surface effect is interestingly comparable. These new kinds of enchanted objects would both bring to present-at-hand themselves, but also bring forth other objects. This would have the interesting effect of causing the user to think about the object creating this kind of ‘flickering object’, which passed between readiness-to-hand and present-at-hand. Secondly, the kinds of goals and projects that people have would be expressed within a computational structure, perhaps real-time streams that are procedural, algorithmic, modular, and quantitatively expressed. Thirdly, the identities or roles that people would have would enable them to take a stand on themselves that would be computational. Self-tracking, life-hacking type monitoring might therefore be turned into a continuous self-reflexive lifestream.

What is the style of the computational world? 


It is deeply algorithmic in nature, surface driven, haptic, and information-centric. The use of conversational interfaces, such as Apple Siri,  is a useful harbinger of this computational future. Here, the user must be disciplined not to be conversational, but rather to be computationally conversational. Many millions of dollars of research money have been spent in an attempt to get computers to understand users' conversational language, this has mostly been a failure. However, it is clear that with a certain limited grammatical and syntactical model of the world, combined with a certain amount of ‘personality’ the conversational interface can present a good enough working interface. This is good enough in as much as it can capture a limited conversational plane, but also teach the user how to talk to these enchanted objects in a particular style. Where here 'style' is taken to refer to the set of practices considered skilful within a particular mode of revealing. 


This style is imperative, based around particular notions of quasi-subjects and quasi-objects, not in a ‘real’ everyday sense, but rather as entities that have various kinds of relational and contextual properties. For example, a particular contact in an address book has a series of properties by virtue of being in the address book, namely they become tagged as quasi-subjective having mobility and locative properties. Also they perform within a web of relations between objects and other quasi-subjects, for example having relationships (e.g. wife, spouse, child, daughter) with other quasi-subjects, location (e.g. home, work), and a face (e.g. through photo recognition). One might say that quasi-subjects and quasi-objects are formed within relational networks that are now modelled in graph theory and performed computationally. Thus the modernist subject of technicity becomes a postmodernist quasi-subject of computationality. A mode of revealing as a set of real-time computational data points producing this computational quasi-subject: the streaming-being.

Notes

[1] The archiving of software and code and digital media more generally is currently being actively engaged with in fields such as software studies, critical code studies, digital humanities and new media. There is often a temptation to think of the software as a discrete 'object' or package, forgetting that software and code are extremely networked and cannot function when taken away from this software ecology. Here, I am thinking of the platform that supports the software/code, such as the particular hardware, software, operating system, network connections, etc. It is certainly clear that currently emulated environments leave a lot to be desired when interacting with previous software and code. Unlike books which are relatively self-contained objects (Foucault notwithstanding) software/code is not readable in the same manner. Merely storing the software, and here I am thinking particularly about the executable binary, will not be enough to access, read, execute and explore the package. But neither is storing the source-code, which requires particular compilers, platforms and processes to reanimate it. In some instances one can imagine that the entire totality of technical society would need to be stored to adequately reanimate software/code – for example highly networked software, like zombie botnets, cascading database systems, networked gaming systems, massively parallel virtual worlds, etc. which runs through and across the internet might be an example of this. Perhaps in the future we will have to be content with accepting that the only way to archive some software systems will be to leave them running in a domesticated virtual scene captured temporally and looped in eternity. The longer the loop of code/ecology, the better the ability for future historians to explore and understand their use and meaning.
[2]  I have also referred to these previously as 'fractured objects'.

Bibliography

Berry, D. M. (2011) The Philosophy of Software: Code and Mediation in the Digital Age, London: Palgrave.

Dreyfus, H. (2004) Being and Power: Heidegger and Foucault, accessed 29/10/11, http://socrates.berkeley.edu/~hdreyfus/html/paper_being.html

Heidegger, M. (1977) The Question Concerning Technology and other Essays, London: Harper & Row.

Winograd, T. and Flores, F. (1987) Understanding Computers and Cognition: A New Foundation for Design, London: Addison Wesley.