After my post of yesterday, Graham Harman made a few helpful observations about the term “object-oriented philosophy.”

First Harman observed that the “parallels seem plenty apt,” that “terms can be borrowed freely across disciplines with slight changes of meaning” that “plenty of other names can be used,” and that “it doesn’t matter unless people have such strong preconceived notions of what object-oriented programming means that they end up confused.”

Then in a later post, Harman excerpted two sides of the OOP debate, one pro and one con, with the con coming from my January post on the subject. Here they are in full for clarity:

The “pro”:

“Weird! When I first came across your blog, I unhesitatingly assumed that the reference to Object-Oriented Programming was deliberate. I’m a software developer for a living, so I can say with confidence that the basic parallels are apt (the whole reason for the term in software development was a change in â??focus’ toward objects that truly interact rather than just data structures and procedures). There are some strong nuances that might not match up (encapsulation, inheritance, polymorphism, etc) but reading those in would have to be pretty intentional and conscious.”

The “con” comes from Ian Bogost’s blog post back in January, which he has kindly re-sent to me:

“My worry arose not from the perception that Harman had absconded with the appellation without giving it proper credit, but because I feared the sense of ‘object-oriented’ native to computer science didn’t mesh well with that of speculative realism.

To wit, an object in the computational sense:

  • describes a pattern, not a thing.
  • exists in stable relation to its properties.
  • exists in stable relation to its abilities.
  • has direct access to other objects via their properties and abilities
  • is not a real object
  • (but can be made real, e.g. on magnetic tape or as a series of instructions on a processor stack)
  • always relates to an intentional object (both because it is a designed

    object and because it strives to embody and enact direct modeling of the world)

Many—perhaps all—of the aspects above conflict with Harman’s understanding of objects and what it means to be oriented toward them (even if certain other properties of object-oriented programming, such as abstraction and polymorphism, might begin to approach the agitated relationship between objects and properties per Harman).

I don’t want to dwell on this subject too much more, but here are my thoughts on the matter:

I agree that this name is one among many, and as such the entire matter is not momentous.

I agree that terms can be borrowed liberally across disciplines. (As I noted in a comment on the January post, “unit operation” is a technical term borrowed from chemical engineering.)

I agree with Harman and the “pro” view that there are strong parallels between “object-oriented philosophy” and “object-oriented programming.”

However, I contend that those parallels sit squarely on the surface of both fields. When we dig down deeper (as I tried to do in the so-called “con” excerpt above), there are also incompatibilities.

And I contend that it’s worth knowing what those are so that one can talk about them when the need arises. Given that “object-oriented programming” is a concept with incredibly wide currency among computer programmers, and given that many people from various walks of life do computer programming, including current and future philosophers, it is reasonable to think that there may actually be strong preconceived notions of what “object-oriented philosophy” means, perhaps even among the folks Harman hopes his work will reach. Indeed, the “pro” response above already confirms that notion.

That’s all really. It’s hardly an indictment. Just an observation that, given the similarities between the terms and their subtle but important differences in meaning, it’s worth understanding those differences deliberately. But not obsessing over them.

published July 16, 2009

Comments

  1. Mike Keesey

    To wit, an object in the computational sense … describes a pattern, not a thing…

    It seems to me that many of these bullet points are actually about classes, not objects. An object is an instance of a class, and, as such, it is a thing.

    Then again, in some languages, classes are instances of a “Class” class. Okay, that’s enough head-hurting for today….

  2. Ian Bogost

    Mike, sure, but the idea of a blueprinting objects has a decidedly transcendental air to it, one that doesn’t jive entirely well with o-o philosophy. A software object is still not an object, either, it’s a representational instance of a (human) ideal, but that’s not really a helpful detail. That said, this whole post was about being measured, and acknowledging that there are similarities and differences.

  3. Asher Kay

    Hey, Ian. I’m the person who sent Graham the “pro” statement. I also sent him the following reply to your “con” statement.

    With all due respect to Ian, I’d say he’s wrong:

    describes a pattern, not a thing.

    In OO Programming, a “class” describes a pattern. An object is a thing (it’s an “instance” of a class). You can think of a class as a “theory” of an object. It enumerates the properties of an object, but more importantly, it defines how that object interacts with other objects.

    The only drawback I see here is that classes add a whiff of Platonism. But I consider the distinction between an object and our formal theory of an object to be important and not at odds with your approach.

    exists in stable relation to its properties.

    Unless it generates its own methods, is prematurely garbage-collected, etc.

    exists in stable relation to its abilities.

    I don’t know what that means.

    has direct access to other objects via their properties and abilities

    This depends what you mean by “direct”. The popular concept of “hidden pointers” makes object access very indirect. In fact, the term “indirection” is used constantly in OO Programming.

    is not a real object

    Au contraire. If Popeye and Singapore are real, a programmatic object surely is.

    (but can be made real, e.g. on magnetic tape or as a series of instructions on a processor stack)

    If it’s an object, it’s already a series of instructions that’s stored somewhere. I don’t know how that really lends it any more reality, though.

    always relates to an intentional object (both because it is a designed object and because it strives to embody and enact direct modeling of the world)

    Once again, unless it is stochastic or codes itself. But the object itself doesn’t really “strive” for anything. The point about modeling, however, is well-taken.

    I think your strongest point is the one about modeling. As you can see in my response, that creates the possibility for a sort of conflation between different conceptual levels.

    I agree with you that it’s not worth obsessing about, so I’ll drop it there 🙂

  4. Ian Bogost

    Asher, thanks for dropping by. Your comment is the same as Mike’s above, more or less. I think calling me “wrong” is overdoing it. I was trying to simplify the comparison, but the important thing is that objects in OOP exist only as instances of patterns, not as isolated vacuum-packed objects, which reeks of more than a little Platonic idealism if you ask me.

    The bit about generating methods is a bit pedantic, yes :)? I was looking for an overall characterization of OOP, not one that accounted for all variants, and I stand by the stable relations point. As for abilities, this is a reference to one of Graham’s terms; think of methods, for example. It’s really the same observation as properties.

    The question of the realness of software objects is a pretty intersting one, maybe the one worth thinking about the most!

  5. Asher Kay

    “I think calling me “wrong” is overdoing it”

    Agreed.

    “The bit about generating methods is a bit pedantic, yes :)?”

    Agreed again ;).

    I think the realness of software objects would also be the most interesting question to Graham, but it’s probably less mind-bending to set the whole OOP analogy aside before getting into that.

    To me, the interesting thing is the idea of an OO program as a “theory”. The classes are the formal theory, the objects are really “models” of objects. Modeling objects in this philosophical sense is (to me) much more interesting than the superficial “Platonism” of it would suggest, because the focus is on how objects “network”, and how they can form complex, dynamic systems that have properties not present in the parts.

    Good to meet you, BTW. It’s weird to come across other software people with philosophical interests. I haven’t done a game since “Reproduction Man”, but your writing here on games is good stuff. So far, I especially liked the “I want my 99 cents back” piece. I actually got a response to my “Boids” app in which the user requested his “free” back ;).

  6. Ian Bogost

    What you’re describing sounds a lot like an ANT approach to OO programming, which seems quite promising of course. It also makes me feel even more that the promising questions about object-oriented philosophy and programming are about the status of programmatic objects rather than about analogies between the two domains, whether for comparison or contrast.

    Hilarous that someone asked for his “free” back. “You wasted my time with your ideas and effort!” Clicked over to your site and find much fodder there, so I’ll plan to peruse it in more detail.

  7. Asher Kay

    I don’t know much about Latour, but yes, I’m sort of thinking along those lines.

    To refer back to Graham’s “metaphysics videogame” idea, you could say that a lot of agent-based computer models are basically “scientific” videogames. Weather models and biological ANNs would fall into this category. The reason a model is needed in these applications (rather than just a set of mathematical formulas) is that the systems being explained are complex and dynamic.

    But some models go further than describing a physical reality. An example from the top of my head would be Axelrod’s model for political alliances. A model like this doesn’t just have actors networking according to rules — it introduces a metaphor that is the basis of the entire model (In this case, the idea that power relations can be represented as energy landscapes).

    In my non-rigorously-proven opinion, metaphors and isomorphisms are at the heart of every conceptualization of reality. A “metaphysical” computer model goes “beyond physics” by showing whether a particular metaphor is apt.

    As I said on one of Levi’s recent posts, I also think that works of art can go beyond what formal, expository descriptions can say, precisely because of their metaphorical nature.

  8. Ian Bogost

    Metaphor is also at the heart of Graham’s idea of causation, and, not just by accident, it’s central to my idea of how to pragmatize (or operationalize, or specify) a speculative realism. So I’m right there with you.