O O

People who program computers have a notion of things being “Object Oriented”, or “O O” in the parlance. This is considered to be a good thing, and yet software systems that use this principle are generally described as “objected oriented programming systems” or OOPS – an acronym which may be tempting fate, to say the least.

The basic notion is borrowed from the physical world – that everything is thought of as an object, whether it be a number, a tree structure, a list of email addresses, or a computer program. You can “talk” to an object by sending it a message, then proceeding to “listen” to what the object has to say for itself. This is admittedly a strangely anthropomorphic way to treat things in a computer.

The real power of this approach comes from the fact that an object can belong to classes of objects that talk or listen in a particular way, and that these classes can be nested one inside the other, which allows you to refer to objects in progressively more specific ways.

We actually do this all the time in the real world. For example, a fruit is a kind of thing to eat, an apple is a particular kind of fruit, and a crabapple is a particular kind of apple. Depending upon what you’re trying to communicate, you might be more or less specific: “I had fruit for desert,” or “I had an apple”, or “I ate a yummy crabapple”.

Similarly, in a computer program, a component is something that you can see in a user interface, a button is a kind of component (one you can click on), and a pop-up button is a kind of button (one that goes away after you click on it). The whole object oriented thing is really a convenient a way of organizing things to make it easier to program, by using concepts that we already understand from real life.

I sometimes wonder whether there are other programming ideas we could borrow from the real world, and how far we could go with those analogies. For example, could we start to think of software objects as being mutual friends? As political rivals? As lovers? In other words, why can’t software objects see each other as objects of affection, or emnity? Or desire?

It might be useful to have a programming object be jealous of another, wishing to wreak revenge. Or for two objects vying to be best friends with the same third object. Presumably this object of their affection would need to decide which of the other two it liked the best – the one with the fancy attributes it just connected with yesterday, or the old reliable object it has been hanging out with since Windows 2000.

We might be able to get ideas about how to organize our programs by looking at the classics – Joyce, Austen, Nobokov, Shakespeare – to understand new and expressive forms of relationships between the things that go on inside a computer program.

For example, a powerful supervisory programming object may have spawned three daughter objects, each of which now claims to be carrying out its commands, but only one of which is truly loyal. Of course the spawning object might not correctly guess which of its daughter objects is the loyal one, and this could have tragic consequences.

Similarly, we could use the evolving relationship between Beatrice and Benedict as a model for error correction, or the path finding techniques of Leopold Bloom to design random walk algorithms, or model message passing protocols after the protocols used by Elizabeth Bennett and Mr. Darcy for, well, message passing.

With a little out of the box thinking, object oriented programming might never again be the same.