Philosophy of object-orientation

This forum has been focusing on one property of object-oriented programming:

data and the routines that are used to understand them are placed together (my summary of Alan Kay)

or the extension of the above, by adding actors:

That’s the Smalltalk style. We know that. Here is something different.

At Programming 2026, Ole Lehrmann Madsen described an understanding, quoting this 1982 paper, https://dl.acm.org/doi/10.1145/988164.988172

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.

This understanding is more relevant to the modeling of the material world, which contains things that exist in time. I think it also suggests that mutability implies lifecycle and subsequently implies the modeling of the material world as a paradigm.

I asked attendees about their experience with this understanding. The students told me they never learned it. The teachers told me they were not teaching it to undergrads. There must be something missing here.

2 Likes

There’s so many of these beautiful ideas that collapse upon hitting the world in which we live. The paper makes these assumptions over and over again, that we can create and destroy things, “just like in the material world”, unfortunately it comes crashing head-on to the the first law of thermodynamics, which states explicitly that we can’t, do just exactly that, creating and destroying things.

The cost exists in the material world, as it exists in the memory in which our programs live. Some people have explored this connection extensively, that connection between resourced based computation and logic. Lafont, for example, and understanding the subtleties of the following two words is important:

The fundamental laws of computation are commutation and annihilation.

If we’re taking the material world as a paradigm, there’s something really interesting that we can look at, linear logic(!), which lives at the core of optimal lambda reduction and seems to coexist with the rules of the natural world. I think there’s definitely a point to be made about looking at how the material world works, and what computation model best maps to that reality.

At least, we might wan to search for something that doesn’t goes straight against the first law of thermodynamics.

Hot take: One thing I could say about the creation and destruction of resources and computation. I think variables/arguments/bindings/clojures are a mistake, they should not exist at all in computation, and if I had to make a prediction, one day, they won’t. Accessing things by name is fundamentally flawed as a resource management mathematics, because it’s based on traditional logic which obfuscates resource consumption and duplication.

FILE * f = new File();
f.destroy()

f.append('c') // error

Names allow to cross the boundary into a world in which things can be accessed, instantiated or destroyed without being aware of the cost, or simply accessed after they have stopped existing, and this distance from how the world in which we live works might be an indication as to why it’s computationally inefficient and error prone. I think the reason why this whole paradigm(as opposed to another without bindings, like tacit programing) leads to needless amount of errors from operating on things that don’t exist, is that same distance.

Anyways, object instantiation/sharing/as-values is a nice idea, one that I’d classify as Mathematically elegant, thermodynamically fictional.

3 Likes

For world modeling, the language should indeed be thermodynamically based. I am curious how such a language will work.

What are some cases where this feature is not needed? Of course mathematics are included.

It might look something like this or that.

The new object is allocated space so that it is independent from existing objects. As a part of its metaphysics, space allocation is enforced by the runtime.

Compare this to nominal type systems[1], where types are distinguished by their names and not their structures.

There is apprently a parallel:

Metaphysics Type system Value interpretation
Nominalism[2] Nominal[1:1] Object and Value are different kinds
Realism[3] Structural[4] Value is the only kind

The last column is my addition. I don’t think I have seen it anywhere.


Also consider the fact that mutability is closely related to Objects:

Now that the parallel above is drawn, we are very tempted to say the following:

Mutability supports nominalism.

Very intriguing! What does this mean?


  1. Nominal type system - Wikipedia ↩︎ ↩︎

  2. Nominalism - Wikipedia ↩︎

  3. Philosophical realism - Wikipedia ↩︎

  4. Structural type system - Wikipedia ↩︎

1 Like

Can you have a modeling language that is capable of stating thermodynamics as optional axioms?

Since things cannot be simply created or destroyed, my understanding is that you intend to describe systems that do not exchange matter with the outside. Which means the boundary of the system must be established to use your modeling language.

Is my understanding correct?

This is what I first think of, because my goal is to construct some kind of language for cognition, and we are not born knowing any such boundaries.

Why do we need object-orientation, apart from what has already been discussed on this forum? Object-orientation provides facilities for identity throughout a lifecycle. The identity of a mutable variable is the variable, or its left value, written down explicitly and statically. The identity of an object is an automatically created name at run time. These names only have the operation of equality (and maybe copying). Crucially, both names and left values only make sense when there is mutability. Otherwise, they are called “bindings”.

Sometimes, we do not need this kind of identity. If we describe a physical system (at least, a classical one), and want to identify something in it, this should simply involve some kind of boundary drawing. After this, we know everything that is inside the boundary, because we are already working with a model. It might make sense to assign some kind of name to these boundaries within physical systems. Then, we track each object throughout the lifecycle. Unless already existing, a boundary can only be created with 0 volume, and be destroyed when it has 0 volume. But we do have to allocate these names, and this shouldn’t be called a violation of thermodynamics. What may be considered a violation of thermodynamics must already be the case before drawing boundaries.

We can only draw boundaries when we already have a model. Somewhat naively, consider the following view of a physical system state:

extract_properties(draw_boundaries(full_state)) -> domain-specific_state

which in extract_properties hides a lot of physical information and also uses a lot of physical information more than once. It is not apparent how some conservation in the physical system maps to some conservation in the domain-specific state. When writing object-oriented code, I think people really just want the domain-specific view to work, without writing the full model, and it gets incorrect really quick.

So, here is how I imagine a linear, thermodynamics-conforming language will be used in this situation.

  • The full model, including its updating algorithm, is written in this language.
  • The boundary recognition and domain-specific view are constructed with a normal language. It can access the full model without restrictions and allocate any amount of space.
  • The view is view-only; input through the view is undefined.
  • The full model defines ways of input.
1 Like