The Theory

1 The Big Idea Was Messaging

Alan Kay coined the term "object oriented" and spent much of the rest of his career regretting it. In a 1998 message to the Squeak mailing list he put it plainly:

The big idea is "messaging".

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.

Alan Kay, 1998

The word he reached for was ma, the Japanese term for that which is in between. Not the things, the space between the things. What matters about a system is not the inventory of its parts but the character of the gaps between them: what crosses, in what form, under whose terms.

The internet is the proof. It is not one giant class hierarchy. It is independent systems sending messages across agreed boundaries, and it has survived fifty years of continuous change precisely because nothing in it inherits from anything else. Biology got there first. A white blood cell meeting a pathogen does not consult a specification; it reads what is on the surface and responds.

Meanwhile the languages that took Kay's name built taxonomies. Classes, hierarchies, the careful modeling of nouns. All of it about internal properties, almost none of it about the space between. The industry kept the word and lost the idea.

2 Compression, Not Abstraction

If messaging is the point, the hard problem is what the messages mean. Two systems built by people who never met have no shared vocabulary, so historically a human wrote the bridge. Every integration, every adapter, every SDK: a person reading one side's documentation and hand-carrying meaning to the other. This is most of what software work has been.

Abject's addition is one method that every object implements:

ask(question: string) -> string

Ask any object a question in plain English and it answers. That is the entire protocol. What makes it more than a documentation string is where the answer comes from.

Abstraction freezes a judgment

An abstraction is a decision someone made at one moment about what mattered, preserved after the reasons for it have moved on. An interface definition, a manifest, a schema: each one throws the implementation away and keeps a summary of it. That summary was someone's judgment, it was lossy when it was written, and it goes stale from the moment it is committed. Anyone working from manifests alone is working from another person's frozen, lossy judgment about a system that has since changed.

Compression re-derives it

An object answering through the ask protocol is not reading a description that someone wrote in advance. It is deriving one, right now, from the real thing: its manifest, its handlers, its actual source. The answer is a compression of the implementation rather than an abstraction over it, and the difference is that a compression can be regenerated. Change the object and the next answer changes with it. Nothing to keep in sync, because nothing was ever stored.

3 The Ultimate Metasystem

Once objects can be interviewed, the bridges build themselves. An email object holding a dinner invitation asks a calendar object it has never met how to save it. The calendar answers with the message shape it accepts. Glue code is generated and the event lands. No SDK, no integration sprint, no meeting between two teams.

The part that is easy to miss is that this is a conversation and not a lookup. The object being asked can interrogate the caller's intent, push back when a request does not fit, propose something adjacent, or redirect entirely. An ambiguous integration becomes a negotiated one. That is a category the old model had no room for, because documentation cannot ask you a clarifying question.

This is the composability ceiling lifting. Systems used to compose only as far as someone had hand-built the connections, so the reachable set of combinations was whatever humans had gotten around to writing. When objects can teach each other, the reachable set is whatever the objects can explain, which is a much larger space and one that grows on its own.

The mechanics of all of this, message envelopes, the introspect interface, proxy generation and self-healing, are specified in the Ask Protocol.

4 Theory and Artifact

In 1985 Peter Naur argued that a program is not really the product of programming. The product is a theory: the working understanding, held in the heads of the people who built it, of what the problem is and why the solution takes the shape it does. Code is a secondary artifact, an imperfect projection of that theory. This is why a codebase whose team has left is so much harder to change than its size suggests. The artifact survived and the theory did not.

Abject takes this literally. Running objects are expendable. They get rewritten, respawned, garbage collected when a better version exists. What accumulates instead is a knowledge base: facts, lessons learned from things that went wrong, insights, references, and patterns distilled from what actually happened rather than from what someone intended to happen.

Patterns as a living vocabulary

This is Christopher Alexander's idea, applied where it was always going to fit best. A pattern names a recurring tension and the structural resolution that answers it. A pattern language is a vocabulary of those resolutions, built from use, revised when the world changes, and worth more than any individual building made with it. Abject grows one from its own execution history, and recalls the relevant entries into later work.

You could throw away every object in the system and rebuild from the knowledge base and the pattern language, and get something that works at least as well.

That is the actual claim. The objects are the artifacts the theory happens to have produced so far.

5 Data, Context, and Interaction

Trygve Reenskaug, who gave us MVC, later worked with James Coplien on an architecture called DCI: Data, Context, Interaction. The observation behind it is that objects modeled as stable domain data are easy to reason about, but real behavior does not live in any one of them. It lives in a scenario that several objects participate in. So DCI keeps the data in the objects, moves the scenario into a Context, and describes the roles objects play while the scenario runs as the Interaction.

Abject extends this from a code structure into a runtime one. You ask for something and a goal is created. The goal is decomposed, the objects that can play the necessary roles are gathered, and work is assigned to them. Messages flow between them until the goal resolves.

Nothing here requires a class hierarchy, and nothing requires an object to know in advance which scenarios it will be useful in. That is the property that lets a system keep absorbing new work without the parts having to be redesigned around it. You can watch a goal go through this cycle in the scrum loop.

6 A Love Letter

Every object can explain itself. Every object can be discovered by conversation rather than by prior arrangement. Workflows compose out of that instead of being hardcoded, and the durable output is a theory rather than a pile of source.

None of this is new. Kay described the shape of it in the seventies, Alexander in the seventies, Naur in the eighties, Reenskaug and Coplien in the two thousands. What was missing was something that could sit in the gaps between objects and handle the ambiguity that rigid interfaces never could. That part is recent. The architecture is older than the model that finally made it work.

So Abject is a love letter to messages, and to the people who kept saying that the space between things is where the design lives, for the several decades when the industry was busy drawing hierarchies.

It is a simple idea but a powerful one. Hard to grasp its scope. Kind of like the Schrödinger equation.

Longform, in the author's own words: A Love Letter to Object Orientation, Entering the Architecture Age, An Abject Horror.