Philosophy of object-orientation

From there the link to the paper requires a login, but it’s also available at the ACM digital library.

It’s heavily steeped in object-orientation of the Java and C++ style, that I question the entire foundation and ontology it’s based on. Not to discredit the work in any way, I mean I’d prefer to build from different first principles. One of the assumptions is the fundamental distinction between objects and values, supported by cited references including:

This gets closer to the heart of what we’ve been discussing so far in this thread: what is the value and cost of object-orientation; whether it is a necessary and useful abstraction, or more of a hindrance and incidental complexity inherited from history; how there may be advantages in deconstructing objects, and instead work with the primitives of values and processes directly without the notion of a mutable state and “identity” (self or this).

Values amount to timeless abstractions for which the concepts of updating, sharing and instantiation have no meaning.

Objects exist in time and, hence, can be created, destroyed, copied, shared and updated.

We can see now an important difference between the domain of mathematics and the domain of computer science.

Mathematics deals with things such as numbers, functions, vectors, groups, etc. These are all abstractions, i.e., values. It has been said that the theorems of mathematics are timeless and this is literally true. Since mathematics deals with the relations among values and since values are atemporal, the resulting relations (which are themselves abstractions and values) are atemporal.

Conversely, much of computer science deals with objects and with the way they change in time. State is a central idea. It might not be unreasonable to call computer science objectified mathematics, or object-oriented mathematics.

  • Programming is object-oriented mathematics.
  • Mathematics is value-oriented programming.

In the context of my recent study, this is directly related to:

The Curry-Howard-Lambek correspondance is a three way isomorphism between types in programming languages, propositions in logic, and objects of a Cartesian closed category.

Here the term “object” has a completely different meaning. (Even the term “term” has a domain-specific meaning.) This is about the structure and relations of mathematical objects.

A category has objects and morphisms, which represent things and ways to go between things.

In physics, the objects are often physical systems, and the morphisms are processes turning a state of one physical system into a state of another system—perhaps the same one. In quantum physics we often formalize this by taking Hilbert spaces as objects, and linear operators as morphisms.

A linear type theory can be seen as a programming language suitable for both classical and quantum computation. This language differs from the typed lambda calculus in that it forbids duplication and deletion of data except when expressly permitted.

To impose these restrictions, linear type theories treat variables very differently than the typed lambda calculus. In fact, in a linear type theory, any term will contain a given variable at most once. But linear type theories depart even more dramatically from the typed lambda calculus in another way. They make no use of lambda abstraction! Instead, they use “combinators”.

Physics, Topology, Logic and Computation: A Rosetta Stone

Well, I tried to bring the discussion back to the topic of object-orientation but still ended up with combinatory logic. A reason is that combinators are a kind of immutable primitives at a lower layer of abstraction, closer to the metal in the domain of mathematics. Object-orientation is, dare I say, an arbitrary abstraction that can be shaped any way you want: one can build such ephemeral “objects” and metaphysical architectures with combinatory or other kinds of logic, but not the other way around.

Conal is one of the people whose ideas have greatly influenced me.

The main idea that you should take from him is denotational programming. In simple terms, you relate specific computations to a specific model that has meaning to the programmer.

You should look at functional réactive programming from this perspective.

@neauoire 's Tote could be seen as having a bag of things and having reactions inside this bag, if the rules were executed out of order.

You should look at his critic of Haskell’s IO monad, for the same reason, that it has no denotational meaning.

It is for the above reasons that I am talking about a modeling language, because then we can replace the IO monad with something that has meaning to the programmer / user.

(More forthcoming when I get some time free)

Edit : John Baez’s paper is really interesting. I will look at it.

1 Like