OOO and OOP

Graham Harman has always denied any deep connection between his Object-Oriented Philosophy and Object-Oriented Programming, from which he borrowed the name. Initially, fellow OOO-er Ian Bogost even resisted the use of “object-oriented” as confusing due to the failure of the computer science sense of the term to “mesh” with the philosophical one.

But, the more I’ve read of Harman and other OOO thinkers, the more I disagree with Bogost. While Harman’s objects are not identical to those that are familiar to programmers, the relationship goes well beyond shared terminology. They are deeply enmeshed, both conceptually and etymologically.

In this post, I’ll try to tease out some of these connections, by looking briefly at two key terms in Harman’s philosophy: “black boxes” and “withdrawal”.

Black Boxes

The term “black box” plays a key role in Harman’s Prince of Networks. In Prince of Networks, Harman reads French sociologist Bruno Latour’s oeuvre in order to spell out the metaphysical system at play within it. He then goes on to define his own Object-Oriented Philosophy by building on – and diverging from – Latour’s ideas.

Latour defines the term “black box” thusly (as cited by Harman in Prince of Networks):

A black box is any actant so firmly established that we are able to take its interior for granted. The internal properties of the black box do not count as long as we are concerned only with its input and output.

Latour deploys the term to solve a key problem in his Actor Network Theory: how can we talk about individual members of the Network when we know that, if we looked more closely, they’d teem with other actants and their relations. We can only consider an individual actant in itself by hiding the other actants that make it up within a “black box” abstraction that reveals only those actants’ collective effects, properties, and relations.

In the sciences, the term “black box” seems to have first appeared in the work of German mathematician Wilhelm Cauer, but it was made famous by Norbert Weiner, the legendary mathematician who created the field of Cybernetics. In Cybernetics: or Control and Communication in the Animal and the Machine (1948), Weiner defined a “black box” as

a piece of apparatus which performs a definite operation on the present and past of the input potential, but for which we do not necessarily have any information of the structure by which this operation is performed.

(Latour explicitly mentions this cybernetic origin when he introduces the term in Science in Action.)

This idea has had many applications in engineering and programming from code breaking to electronics to the design of programs in the intervening 65 years.

In its most common programming usage, the “black box” stands for the principle of abstraction: the goal that individual components should be built with as few assumptions as possible about the wider system so that they can be reused in different situations without needing to be changed.

Latour’s use of “black box” is perfectly resonant with its mathematical and programming usage. As is Harman’s.

Harman adopted the term from Latour to battle what he calls the “undermining” instinct: the tendency to reduce an object to its components. An underminer would look at the laptop on which I’m composing this blog post and say: well the laptop is really just a collection of aluminum, glass, and silicon components. And those components are really just collections of atoms. And the atoms are really just collections of sub-atomic particles. And the sub-atomic particles are really just probability waves in a vacuum.

Harman deploys the black box in defense against this, essentially nihilistic, gesture. The black box allows Harman to think about objects as unitary wholes, with their own effects and relations distinct from those of their components, even while knowing that they contain complex networks of other objects inside of them. Again from Prince of Networks:

The black box replaces traditional substance…while traditional substances are one, black boxes are many – we simply treat them as one, as long as they remain solid in our midst. Like Heidegger’s tools, a black box allows us to forget the massive network of alliances of which it is composed, as long as it functions smoothly.

The distinction between Harman’s use of “black box” and Weiner’s is subtle. For Harman, an object has effects and relations in excess of those of its components. For Weiner, a black box represents a (frequently voluntary) boundary of knowledge. How an object transforms its input into its output may be completely determined by the objects inside its black box, but we either can’t, or choose not, to know exactly how they contribute to that process. However, in the practice of programming our black box abstractions always do have effects beyond simply hiding their internals. The abstractions we inherit and choose to create play a major role in the social and technical evolution of our systems, helping to determine the boundaries between different pieces of software, teams and companies, and even pieces of hardware infrastructure. They certainly have effects and relations distinct from their components.

Withdrawal

“Withdrawal” is an even more interesting example of this resonance. Withdrawal is a core concept in Harman’s thought. It is what gives objects their continuity over time and their persistence despite change.

For Harman, real objects withdraw. There’s always more to them than the qualities and relations we observe them to posses. Harman calls the part of the object we can observe and relate to the “sensual object” in distinction to this “withdrawn object”.

In Prince of Networks, Harman introduces withdrawal in order to solve a problem he saw in Latour with the continuity of objects. For Latour, an object is nothing more than its relations. Objects (or “actants” in Latour’s terminology) sit in a network of other objects, acting as their supporters, components, evidence, masters, associates, etc. They are entirely determined by these relations. However, Harman observed that if any of these relations changed (which they obviously do over time) then, in this understanding, the object must cease to exist and become a different object (objects being nothing more than their relations).

For Latour, the demitasse out of which I drink my espresso becomes a fundamentally different object when the barista fills it, another different one when she passes it to me, and a third, fourth, fifth, and sixth with each sip I take from it. Six completely different objects.

Harman observed that this point of view makes it hard to think about change. There’s no object that persists through this series of alterations, undergoing changes. He introduced withdrawal to explain change. The withdrawn object is what persists even as its qualities and relations change.

How does this relate to Object-Oriented Programming? Let me explain through some example code.

In Ruby, when you create a new object, it has an object_id:

o = Object.new
puts o.object_id
#=> 70152737816360

This object_id is just a number. The Ruby environment uses it to remember where the object is located in memory, but it is independent from the particulars of the object itself.

You can add data to the object by defining instance variables on it:

o.instance_variable_set("@name", "spot")

and its object_id won’t change:

puts o.object_id
#=> 70152737816360

even though the data is now there:

puts o.instance_variable_get("@name")
#=> "spot"

You can also remove data without affecting the object_id:

o.send(:remove_instance_variable, "@name") 
puts o.object_id
#=> 70152737816360
o.instance_variable_get("@name")
#=> nil 

And, of course, the same thing holds for adding and removing methods:

def o.cat!
    puts "meow"
end

def o.dog!
    puts "arf"
end

o.cat!
#=> "meow"
o.dog!
#=> "arf"
puts o.object_id # no change
#=> 70152737816360 

class << o
    remove_method(:dog!)
end

o.dog!
#=> NoMethodError: undefined method `dog!'...
puts o.object_id # no change
#=> 70152737816360 

In a very real way, a Ruby object’s id is the essence of the object; it’s how the system knows where to find the object in memory. If the object_id was somehow removed or changed the object would be lost. On the other hand, the object_id is utterly uninteresting. It doesn’t tell us anything about the object’s data or methods – the parts of the object that interact with other objects and that we spend most of our time thinking about and manipulating.1

This is profoundly parallel with Harman’s idea of withdrawal. The object_id is an analogue for Harman’s withdrawn object while the methods and data make up the “sensual object” we perceive and to which we (and other objects) relate.

One common misinterpretation of Harman’s position is to imagine that the withdrawn portion of the object is always its most important part, even its “soul”. However, as spelled out in The Quadruple Object, Harman’s system sees objects as having a four-fold structure. And, in some regards, the withdrawn object is the least interesting of the four. Just like the Ruby object_id, even though the withdrawn object is mysterious and inaccessible, it doesn’t determine the object’s qualities and relations, which are frequently what we’re most interested in.

Politics and the Fear of Technical Associations

There are many additional facets of Object-Oriented Philosophy that have similarly interesting relations to Object-Oriented Programming. There’s probably a dissertation-scale study to be done just in comparing Harman’s thought with that of Alan Kay, the legendary computer scientist who coined the phrase “object-oriented programming”. Such a study could serve as an intellectual history tracing the movement of these ideas back and forth between technical and philosophical disciplines, provide a source of additional philosophical material unearthed by computer scientists, and introduce a new axis for understanding the work of computer scientists by unpacking their various philosophical positions.

However, I find it very unlikely that such work will be done in a philosophy department any time soon – and not just because of the difficulties involved in mastering both the computer science and philosophical technicalities involved (after all, Harman’s work reading Latour as a philosopher required a similar engagement with the sociological specificities of that oeuvre).

One of the chief criticisms leveled against OOO is political, specifically that it fails to provide a basis for radical political action against the state. Alex Galloway has been maybe the most-prominent spokesman for this position, accusing Harman of “depoliticization and neutralization” and arguing that politics must precede other forms of thought: “to be political means that you have to *start* from the position of incompatibility with the state”.

Galloway blames these political failings exactly on OOO’s technical heritage, arguing that “OOO is politically naive because it parrots a kind of postfordist/cybernetic thought”. Essentially saying that OOO’s roots in programming make it complicit with “digital capitalism”.

Harman, and other OOO thinkers, have responded vigorously to this critique (see Bryant and Donkey Hottie, amongst many others). In addition to criticizing the weak ties that Galloway sloppily used to bind OOO to “digital capitalism”, the OOOers have, validly questioned Galloway’s basic premise that politics must always precede and determine other forms of philosophical inquiry.

Despite this vigorous defense, these kinds of attacks have left OOO with a lasting fear of an over-close association with technical fields like computer science and programming. This is a serious shame as it obscures a significant part of OOO’s heritage, prevents what could be a powerfully productive interdisciplinary collaboration, and (maybe worst) leaves OOO’s critics as the only voices defining this connection.

  1. The class of a Ruby object is also unchangeable, but this feels like a way that Ruby is a bit more “class-oriented” than “object-oriented”. Relatedly, one of Bogost’s objections to the philosophical use of object-oriented was that computational objects “describe a pattern, not a thing.” I think Bogost, here, mistakes classes, which are patterns for objects with the instantiated objects themselves, a common and understandable slippage since in most mainstream object-oriented languages, like Ruby, programmers spend much more of their time thinking about and writing classes than they do manipulating individual objects as I’ve been doing in this example code.)
This entry was posted in Opinion. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *