Everything Is an Object, Everything Is a Message

smalltalk1-2 left a question open: what part of Kay's original vision got left behind by most of Smalltalk's own descendants? This chapter is the full answer — the single idea most languages softened, split, or abandoned entirely: literally everything in Smalltalk is an object, and the only thing you can ever do to an object is send it a message.

The Core Claim — Literally Everything Is an Object

Every value in Smalltalk is an object — numbers, booleans, characters, strings, arrays, and even classes themselves (which are instances of their own "metaclass"). There is no primitive-versus-object split anywhere in the language — no int distinct from Integer, no primitive boolean sitting outside the object system the way Java famously keeps them separate (java1-2's own primitive-vs-reference-type material), or the way C#'s own value-type structs (csharp1-2) are a genuine, deliberate middle ground but still not full objects receiving messages the Smalltalk way.

Concretely: 3 + 4 in Smalltalk is not "the + operator applied to two primitive integers." It is literally sending the message + to the object 3, with the argument 4. The number 3 is a real object that receives a message and responds with a result — another object, 7.

Even Control Flow Is Message Sends

Here's the genuinely radical detail. ifTrue:ifFalse: is not built-in syntax the way if/else is in virtually every other language covered on this site — Java, C#, C++, Kotlin, Python, all of them. It's an ordinary message, sent to a Boolean object, carrying two block arguments (Smalltalk's own closures) representing "what to do if true" and "what to do if false." True and False are actually two separate classes, each independently implementing ifTrue:ifFalse: to do the obvious thing for its own case.

This has an astonishing structural consequence: because ifTrue:ifFalse: is just an ordinary method on a class, nothing in principle stops a third boolean-like class from implementing its own version — something structurally impossible in any language where if is baked directly into the compiler or interpreter's fixed grammar. Loops work identically: whileTrue: is a message sent to a block, not built-in loop syntax either.

Why This Matters — Uniformity as a Design Principle

The payoff of this radical uniformity: there is exactly one mechanism in the entire language — sending a message — and it applies everywhere, with no special cases. Compare this to virtually every other language on this site, each of which has at least two tiers: "the stuff that's really built into the language's own grammar" (if/else, loops, operators on primitives) and "the stuff that's just regular code" (method calls, user-defined types). Smalltalk collapses this into one tier, entirely.

Direct Contrast — Dispatch in Other Languages on This Site

The throughline across every one of those languages: each treats "the fixed set of things the language itself natively understands" as separate from "user-extensible object behavior." Smalltalk has no such separation anywhere — even arithmetic and control flow live entirely inside the same, single, uniform mechanism as every user-defined class's own methods.

A Worked Example — A Conditional as Pure Message Sends

Walking through x > 5 ifTrue: ['big'] ifFalse: ['small'] one message at a time: first, x > 5 sends the message > to the object x, with argument 5 — this returns a Boolean object, either true or false. That Boolean object then receives the message ifTrue:ifFalse:, carrying the two block arguments. The Boolean itself — not some special interpreter-level "if" logic — decides which block to actually evaluate and return, purely through its own class's own method implementation.

Reflection Questions