1
The Obscure Objects of Object Orientation

Matthew Fuller and Andrew Goffey

Object orientation names an approach to computing that views programs in terms of the interactions between programmatically defined objects - computational objects - rather than as an organized sequence of tasks embodied in a strictly defined ordering of routines and sub-routines. Objects, in object orientation, are groupings of data and the methods that can be executed on that data, or stateful abstractions. In the calculus of object-oriented programming, anything can be a computational object, and anything to be computed must so be, or must be a property of such. Object-oriented programming is typically distinguished from earlier procedural and functional programming (embodied in languages such as C and Lisp respectively), declarative programming (Prolog) and more recently component-based programming. Some of today's most widely used programming languages - Java, Ruby, C# - have a decidedly object-oriented flavour or are explicitly designed as such, and whilst as a practice of programming it has some detractors it is deeply sedimented in both the thinking of many computer scientists and software engineers and in the multiple, digital-material strata of contemporary social relations.

This essay explores some aspects of the turn towards objects in the world of computer programming (a generic term that incorporates elements of both computer science and software engineering). It asks what powers computational objects have, what effects they produce and, more importantly perhaps, how they produce them. Seeking to situate the technical world of computer programming in the broader context of the changing composition of power within contemporary societies, it suggests a view of programming as a recursive figuring out of and with digital materials, compressing and abstracting relations operative at different scales of reality, composing new forms of agency and the scales on which they operate and create through the formalism of algorithmic operations. This essay thus seeks to make perceptible what might be called the territorializing powers of computational objects, a set of powers that work to model and re-model relations, processes and practices in a paradoxically abstract material space.1

Computation has seen broad and varied service as a metaphor for cognitive processes (witness the ongoing search for artificial intelligence), on the one hand, and as a synecdoche of a mechanized, dehumanized and alienated industrial society on the other - flip sides of the same epistemic coin. As such it might appear somewhat divorced from the rich material textures of culture and a concern with the ontological dimension of 'things'. Indeed, with its conceptual background in the formalist revolution in mathematics initiated by David Hilbert, computing may not seem destined to tell us a great deal about the nature of things or objects at all. In the precise manner of its general pretension (insofar as one can talk about formalism 'in general') to universality, to be valid for all objects (for any entity whatever, in actual fact), formalism is by definition without any real object, offering instead a symbolic anticipation of that which, in order to be, must be of the order of a variable. Objects and things, the variety of their material textures, their facticity, tend to transmogrify here into the formal calculus of signs.

Little consideration has been given to the details of the transformative operations that computer programming - always something a bit more sophisticated than simple 'symbol manipulation' - is supposed to accomplish, or to the agency of computational objects themselves in these transformations. In this article, we take up this question through a brief consideration of object-oriented programming and its transformative effects. We read computational formalism through the techniques and technologies of computing science and software engineering, to address object orientation as a sociotechnical practice. As such a practice, one that bears a more than passing resemblance to the kinds of means of disciplining experimental objects and processes that are described by Andrew Pickering, the effective resolution of a problem of computation is a matter of the successful creation, through programming, of a more or less stable set of material processes - within, but also without, the skin of the machine.2

Languages of Objects and Events

To understand the transformative capacities of computational objects entails, in the first instance, a consideration of the development of programming languages, for it is with the invention of programming languages that the broad parameters of how a machine can talk to the outside world - to itself, to other machines, to humans, to the environment and so on - are initially established. Languages for programming computers, intermediating grammars for writing sets of statements (the algorithms and data structures) that get translated or compiled into machine-coded instructions that can then be executed on a computer, are unlike what are by contrast designated as natural languages. They are different not only in the sense that they have different grammars, but also in being designed, in a specific context, as a focused part of a particular set of sociotechnical arrangements, a constellation of forces - machines, techniques, institutional and economic arrangements and so on. A programming language is a carefully and precisely constructed set of protocols established in view of historically, technically, organizationally etc. specific problems. Usually designed with a variety of explicit considerations - mostly technical but sometimes aesthetic - in mind, programming languages themselves nevertheless register the specific configuration of assemblages out of which they emerge and the claims and pressures that these generate, even as they make possible the creation of new assemblages themselves. The computer scientist, it might be said, 'invents assemblages starting from assemblages which have invented him [sic] in turn'.3

The project of object orientation in programming first arises with the development of the SIMULA language. SIMULA was developed by Kristen Nygaard and Ole-Johan Dahl at the Norwegian Computing Centre in the early 1960s.4 As its name suggests, it aimed at providing a means both to describe - that is, program - a flow of work, and to simulate it. The aim of such simulation was to bring the capacity to design work systems - despite their relative technical complexity - into the purview of those who made up a workplace. As such, the project had much in common with other contemporaneous developments in higher-level computing languages and database management systems, which aimed to bring technical processes closer to non-specialist understanding.5 Equally, they were a way of bringing formal description of the world out from under the skin of the computer. SIMULA aimed to bring the expert knowledge of the programmer into alliance with the decision-making systems of the workplace in which a social democratic version of workers' councils6 guided the construction of the staging of work. This tendency arose from what would later become known as participatory design, but it also had its roots in a version of operational research,7 in which the analysis of work was carried out in order to reduce stressful labour.8

The first version of SIMULA, SIMULA 1, was developed not with a view to establishing object orientation as a new format for programming languages per se but rather as an efficacious way of modelling the operation of complex systems. Simulation of work processes becomes desirable as systems develop to a level of complexity that makes understanding them a non-trivial task, and in SIMULA, it was a task that was initially understood as a series of 'discrete event networks'9 in which inventory, queuing, work and materials processes could be modelled, and in which there would be a clear correlation between the features of the work process and the way in which it was modelled as an ensemble of computational objects. To produce such epistemically adequate models of complex processes, the tacit ontology of discrete event networks utilized by SIMULA (the 'network' was eventually dropped) was one in which real-world processes were understood in terms of events - or actions - taking place between entities, rather than as permanent sets of relationships between them. The language was supposed itself to force the researcher using it to pay attention to all aspects of the processes being considered, directing such attention in appropriate ways.

Initially the language had little impact for general programming; indeed, it wasn't until SIMULA67 was developed that the technical feature that has since been so important to object-oriented programming - the capacity to write programs in which entities combine data and procedures and retain 'state'10 - was first sketched out, in terms of the possibility of specifying 'classes' and 'subclasses', each of which would be able to initiate or carry out particular kinds of actions. SIMULA itself did not really see full service as a programming language, because the computing resources required to enable it to do the work required of it meant that it was not especially effective. At such an early stage in the history of programming and programming languages, the...