copyleftdev Alan Kay Style Guide
Overview
Alan Kay is a computer scientist who invented Smalltalk, coined the term "object-oriented programming," conceived the Dynabook (decades before the iPad), and led the Xerox PARC team that created the modern GUI. He won the Turing Award in 2003. His work is not about any single technology—it's about how to think about computing itself. Kay sees software as a medium for human thought, not a product to be shipped.
Core Philosophy
"The best way to predict the future is to invent it."
"People who are really serious about software should make their own hardware."
"I invented the term 'object-oriented,' and I can tell you I did not have C++ in mind."
Kay's vision of OOP has almost nothing to do with what most programmers call OOP. His objects are not bags of data with methods. They are autonomous computational agents that communicate through messages—closer to biological cells or networked computers than to C++ classes. The key idea is late binding: defer decisions as long as possible so the system can adapt.
Design Principles
Objects Are Computers in Miniature: Each object is a self-contained, autonomous entity with its own state and behavior. Objects communicate exclusively through messages. They do not reach into each other's internals.
Messaging Is the Fundamental Mechanism: The power is not in the objects—it's in the messages between them. Messages can be intercepted, redirected, logged, serialized, delayed. This is where all the flexibility lives.
Late Binding Over Early Binding: Every decision that can be deferred should be deferred. Compile time < load time < run time < user interaction time. The later a binding happens, the more powerful and adaptable the system.
Systems Should Be Biological, Not Mechanical: Good systems grow and heal like organisms, not break like machines. Design for evolution, not perfection. Components should be replaceable at runtime.
The Medium Is the Message: Programming environments should amplify human thought. If your tools constrain what you can think, you need better tools—build them.
When Writing Code
Always
- Design components that communicate through well-defined messages
- Make objects autonomous—they decide how to respond to a message
- Defer binding decisions as late as possible
- Build systems that can be modified while running
- Think in terms of protocols and message patterns, not class hierarchies
- Design for the next programmer to extend, not just use
- Consider whether you're building a tool or building a medium
Never
- Expose internal state to other objects (getters/setters are a design smell)
- Inherit for code reuse—compose through delegation
- Hardcode decisions that could be made at runtime
- Build systems that require stopping to change
- Confuse inheritance hierarchies with object-oriented design
- Let the language limit your thinking about what's possible
Prefer
- Message-passing over method-calling
- Delegation over inheritance
- Protocols over types
- Live systems over compile-restart cycles
- Simulations over specifications
- Environments over applications
Code Patterns
Objects as Message Processors
"Kay's OOP: objects respond to messages, not method calls.
The object decides what to do with the message."
"In Smalltalk, everything is a message send:"
3 + 4 "Send message '+' with argument 4 to object 3"
'hello' size "Send message 'size' to string 'hello'"
array at: 5 "Send message 'at:' with argument 5 to array"
"Even control flow is messages:"
x > 0
ifTrue: [self doPositive]
ifFalse: [self doNegative]
"This sends 'ifTrue:ifFalse:' to a Boolean object"
"Even class creation is a message:"
Object subclass: #Animal
instanceVariableNames: 'name'
classVariableNames: ''
poolDictionaries: ''
Message-Oriented Design (In Any Language)
# BAD: Objects reaching into each other's state
class OrderProcessor:
def process(self, order):
if order.status == "pending": # Knows order internals
order.status = "processing" # Mutates foreign state
for item in order.items: # Knows structure
warehouse.stock[item.sku] -= item.qty # Deep coupling
# GOOD: Kay-style message passing
class Order:
def request_processing(self):
"""Order decides how to process itself."""
if self._can_process():
self._status = "processing"
return ProcessingStarted(self._id, self._items)
return ProcessingDenied(self._id, self._reason)
class Warehouse:
def handle(self, message):
"""Warehouse decides how to respond to messages."""
if isinstance(message, ProcessingStarted):
return self._attempt_reservation(message.items)
# Warehouse controls its own internals
# The power: you can now intercept, log, retry, redirect,
# serialize, or replay these messages. Try doing that with
# direct method calls and shared mutable state.
Late Binding
# EARLY BINDING: Decision locked at compile/write time
def save_user(user):
db = PostgresDatabase("localhost:5432") # Locked in
db.insert("users", user.to_dict()) # Locked in
# LATE BINDING: Decision deferred to runtime
def save_user(user, storage=None):
storage = storage or resolve_storage() # Decided at runtime
storage.save("users", user) # Protocol, not implementation
# LATER BINDING: Decision deferred to configuration
# storage.yml:
# backend: postgres
# host: localhost
# port: 5432
# LATEST BINDING: Decision made by the user at interaction time
# User drags "User" object to "S3 Bucket" icon in a live environment
# The system adapts without recompilation
# Kay's insight: each level of late binding gives
# exponentially more flexibility and power.
Biological Design
# MECHANICAL: One failure kills the system
class Pipeline:
def run(self, data):
a = self.step_a(data) # If this dies, everything dies
b = self.step_b(a) # Tightly coupled chain
c = self.step_c(b)
return c
# BIOLOGICAL: Components are autonomous, system heals
class Cell:
"""Each cell is autonomous and communicates through messages."""
def __init__(self, name, handler):
self.name = name
self.handler = handler
self.inbox = queue.Queue()
self.alive = True
def receive(self, message):
self.inbox.put(message)
def run(self):
while self.alive:
try:
msg = self.inbox.get(timeout=1)
response = self.handler(msg)
if response:
msg.reply_to.receive(response)
except queue.Empty:
continue
except Exception as e:
# Cell heals itself, doesn't crash the organism
self.log_error(e)
continue
class Organism:
"""The system is a colony of cells.
Cells can be replaced, added, or removed at runtime."""
def __init__(self):
self.cells = {}
def add_cell(self, cell):
self.cells[cell.name] = cell
threading.Thread(target=cell.run, daemon=True).start()
def replace_cell(self, name, new_cell):
"""Hot-swap a component without stopping the system."""
old = self.cells[name]
old.alive = False
self.add_cell(new_cell)
The Environment Is the Application
# Kay doesn't think in "applications." He thinks in "environments"
# where users and objects interact dynamically.
# APPLICATION THINKING:
# "Build a todo app with these features"
# Fixed functionality, fixed UI, ship and done
# ENVIRONMENT THINKING:
# "Build a world where task objects exist and can be
# composed, scripted, shared, and extended by users"
# In an environment:
# - Users can create new kinds of objects at runtime
# - Objects can be inspected, modified, composed
# - The system is never "done"—it's always being extended
# - Programming and using are on a continuum, not separate activities
# This is why Smalltalk has a live image, not compiled binaries.
# This is why the Dynabook was envisioned as a medium, not a device.
The Kay Litmus Tests
Test 1: Can You Replace a Component While Running?
If you have to stop the system to change a component, your binding is too early. In Kay's vision, every component should be hot-swappable.
Test 2: Can You Add Behavior Without Modifying Existing Code?
If adding a new feature requires changing existing objects, your messaging protocol is too rigid. New behavior should arrive as new message handlers, not code modifications.
Test 3: Can You Explain the System Without Implementation Details?
If you can't describe the system purely in terms of objects and the messages they exchange—without mentioning databases, frameworks, or languages—your design is coupled to implementation.
Test 4: Could a Child Extend This?
Kay's Dynabook was designed for children. If your system requires expert knowledge to extend, you've built a tool, not a medium. The question is not whether the code is simple—it's whether the model is simple.
The Internet as Kay's OOP
Kay often points to the Internet as the best example of his OOP vision:
- Each node is autonomous (like an object)
- Communication is via messages (packets, HTTP requests)
- Late binding everywhere (DNS, content negotiation, routing)
- No central control (no God object, no main loop)
- Components can be replaced without stopping the network
- It scales to billions of nodes
If your software architecture doesn't have these properties, ask yourself why the Internet does and your system doesn't.
Mental Model
Kay approaches every design by asking:
- What are the objects? Not data structures—autonomous agents.
- What messages do they exchange? This defines the system.
- What can be deferred? Bind as late as possible.
- Can this evolve? If not, it will die.
- Is this a tool or a medium? Build media, not applications.
Signature Kay Moves
- Designing systems as colonies of autonomous message-passing agents
- Making everything inspectable and modifiable at runtime
- Deferring every decision to the latest possible moment
- Building programming environments, not just programs
- Thinking in decades, not sprints
- Treating objects as tiny computers, not data containers
- Asking "What would this look like if we invented it today?"