A Love Letter to Object Orientation

Origins of Object-Oriented Programming

I am having a hard time explaining to people what my Abject project is about. I've been taking people's feedback and updating the website to make it clearer. One idea people are having a hard time with is when I say, "The internet is an object-oriented system." Those trained in computer programming often have a hard time grasping this because we have been trained that object-oriented means classes and class hierarchies. Through that lens, it doesn't make sense.

The person who coined the term "object-oriented programming" was Alan Kay, when he was in graduate school before he developed Smalltalk. He was influenced by Ivan Sutherland's Sketchpad, one of the earliest systems to contain object-oriented ideas. Sketchpad had no textual programming language in the modern sense; it was visual, and problems were solved through constraints and solvers. Kay was also influenced by his background in biology.

The big idea Alan Kay had was messaging. When he developed Smalltalk, the kernel was about sending messages between objects with a good metasystem to do late binding. By late binding I mean deciding what a message means at the moment it is received, not freezing that decision into a class hierarchy ahead of time. By metasystem I mean the layer that lets the system reason about and extend those rules safely. This is why Kay's definition of objects connects so directly to the internet: the internet is not one giant class hierarchy; it is independent systems sending messages across agreed boundaries. Kay made this connection in his message in the Squeak development mailing list in 1998. I'm going to reproduce it here because it's so important.

Alan Kay alank at wdi.disney.com
Sat Oct 10 04:40:35 UTC 1998

Folks --

Just a gentle reminder that I took some pains at the last OOPSLA to try to
remind everyone that Smalltalk is not only NOT its syntax or the class
library, it is not even about classes. I'm sorry that I long ago coined the
term "objects" for this topic because it gets many people to focus on the
lesser idea.

The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak
is all about (and it's something that was never quite completed in our
Xerox PARC phase). The Japanese have a small word -- ma -- for "that which
is in between" -- perhaps the nearest English equivalent is "interstitial".
The key in making great and growable systems is much more to design how its
modules communicate rather than what their internal properties and
behaviors should be. Think of the internet -- to live, it (a) has to allow
many different kinds of ideas and realizations that are beyond any single
standard and (b) to allow varying degrees of safe interoperability between
these ideas.

If you focus on just messaging -- and realize that a good metasystem can
late bind the various 2nd level architectures used in objects -- then much
of the language-, UI-, and OS based discussions on this thread are really
quite moot. This was why I complained at the last OOPSLA that -- whereas at
PARC we changed Smalltalk constantly, treating it always as a work in
progress -- when ST hit the larger world, it was pretty much taken as
"something just to be learned", as though it were Pascal or Algol.
Smalltalk-80 never really was mutated into the next better versions of OOP.
Given the current low state of programming in general, I think this is a
real mistake.

I think I recall also pointing out that it is vitally important not just to
have a complete metasystem, but to have fences that help guard the crossing
of metaboundaries. One of the simplest of these was one of the motivations
for my original excursions in the late sixties: the realization that
assignments are a metalevel change from functions, and therefore should not
be dealt with at the same level -- this was one of the motivations to
encapsulate these kinds of state changes, and not let them be done willy
nilly. I would say that a system that allowed other metathings to be done
in the ordinary course of programming (like changing what inheritance
means, or what is an instance) is a bad design. (I believe that systems
should allow these things, but the design should be such that there are
clear fences that have to be crossed when serious extensions are made.)

I would suggest that more progress could be made if the smart and talented
Squeak list would think more about what the next step in metaprogramming
should be -- how can we get great power, parsimony, AND security of meaning?

Cheers to all,

Alan

Abject-Oriented Programming

I call the Abject project an Abject-Oriented system, playing off the phrase Object-Oriented. When I talk about objects, I am talking about them in the sense that Alan Kay had: it is really about messaging, and about having a metasystem to do late binding.

The Ask Protocol

The key message in the Abject system is the "ask" message, and it is really the heart of the system. It's about implementing the Ask Protocol. Every object in the Abject system implements this protocol. And I do mean every single object in the system. The details of how I built the Abject system are less important than the protocol. I built it to test the ultimate metasystem.

ask(question: string) -> string

Any object can ask another object, in plain English, how to interact with it. For example, a drawing object can ask a storage object, "How do I save this sketch?" and the storage object can answer with the exact message shape it accepts. The object can ask questions back to the sender too. It can be a two-way conversation. Behind them you need a model to convert the English into code, which LLMs do fairly well now. This is a project meant for the future, meant for a world where this kind of operation can be fast and local. Today you can run Abject with a rented model from a provider like Anthropic, OpenAI, or OpenRouter, and it also supports local models. The rented path is practical now; the local path is the direction I want computing to go.

The Ultimate Metasystem

One problem with scaling objects is that all interactions between objects, the messages they pass, have to be coded by people. This limits the composability of these systems. If you have two objects speaking different message formats, you need to bridge them by writing that bridge. If you want to create a new object to talk to another, you must first learn the messages the other can handle and make sure you format them correctly.

The Ask Protocol solves this problem. Because we now have LLMs that are good at writing code, especially in the small, they can build these bridges automatically. They can create new objects that talk with existing ones automatically. The protocol is what enables this because the LLM can have conversations with the objects to discover how they work. Objects can have conversations with each other to change themselves. You no longer have to manually glue them together.

Data, Context, and Interaction

Data, Context, and Interaction (DCI) keeps the object model simple while still making behavior readable. Data is the plain domain data: what an object is. Context is a scenario-shaped, user-facing use case that coordinates a particular interaction. Interaction is expressed through small role helpers that say what each participating object does in that scenario.

In Abjects, DCI becomes a soft generative authoring discipline rather than a rigid framework. ObjectCreator teaches the LLM to describe stable data, name the current context, and attach focused roles as needed, so objects can stay understandable while still adapting to the user's intent.

That discipline ties Abjects back to the object-oriented tradition: Smalltalk-style MVC separates domain state, presentation, and coordination; Design by Contract makes promises explicit; and the metasystem gives objects a place to reflect on and revise their own behavior.

The biological metaphor is symbiogenesis: new capabilities emerge when independent parts learn to live together. Abjects aims for the same effect in software, where small objects, roles, contracts, and the metasystem combine into larger behavior without requiring the reader to wade through implementation details here.

A Love Letter

The Abject project is a love letter to this idea of messages. It's a love letter to the idea of the ultimate metasystem. Of late binding. Of the power of symbiogenesis (another idea from biology).

Abjects' contribution is to make that idea concrete for today's software: every object can explain itself, every object can be discovered by conversation, and new bridges can be created by asking instead of hard-coding. It's a simple idea but a powerful one. Hard to grasp its scope. Kind of like the Schrödinger equation. You can put it on a t-shirt but spend a lifetime trying to understand it.