Kay often criticized systems that lock in a predefined data structure (schema) too early.

A schema (like in relational databases or strongly structured APIs) assumes:

We know the shape of the data ahead of time

All participants will agree on the structure

The structure will remain relatively stable

Kay believed this assumption is usually wrong in real systems because:

requirements change

systems evolve

different components want different representations

So schemas tend to reduce flexibility and make evolution harder.

Kay’s original idea of object-oriented programming was:

Objects communicate by sending messages, not by sharing data structures.

Instead of this:

System shares schema:
User {id, name, email}

Kay preferred something like:

sendMessage(user, "emailAddress")

The receiver decides how the information is stored or computed.

Advantages:

internal representation can change

no global schema coordination

systems are more modular

In Kay’s view, shared schemas couple systems together too tightly.

Kay strongly advocated late binding:

decisions made at runtime

objects can evolve independently

behaviors matter more than structure

Schemas push the opposite direction:

early binding

structural agreement required ahead of time

Kay often argued that behavioral interfaces (messages) are more powerful than structural contracts (schemas).

Kay frequently used biological metaphors.

Cells communicate by signals, not by exposing their internal structure.

Similarly, software components should interact via messages, not shared schemas.

So instead of:

shared database schema

Think:

independent agents sending messages

Kay didn’t hate databases, but he disliked when:

the schema becomes the architecture

systems revolve around data tables instead of objects

He argued that relational schemas often become a global coupling point, making systems brittle.

Alan Kay’s position was roughly:

Schemas are useful locally

But dangerous as global contracts

Systems should depend on messages and behavior, not shared data structures

Flexibility and evolution matter more than structural agreement

“Don’t ask for the data. Ask the object to do something.”