The Message Myth with Avdi
Avdi here. Lately I’ve been spending most of my time working on a talk for the Southeast Ruby conference in Nashville, TN. So, for today’s episode I thought I’d give you a little peek at a section of this talk. It’s about something we talk about a lot on this show: the object-oriented concept of sending messages.
Video transcript & code
The Message Myth
...something we talk about a lot...
Early in my career I thought OO was all about calling methods.
What did it mean to call a method?
Well, it meant we invoke a procedure on an object, instead of passing a data structure to a procedure.
Later, I learned that OO was really supposed to be about sending messages.
In fact, Alan Kay even said he regretted calling it object-oriented programming, because the focus really should have been on messages.
Even later, I learned from Sandi Metz that I should stop trying to identify objects first.
Instead, I should identify the message I wanted to send, and then figure out what object should receive that message.
This made things a LOT easier!
So what is the difference anyway between messages and methods, anyway?
Here’s how I learned it: when we send a message, the object we send it to gets to decide what procedure to run.
Different objects can implement different methods for the same message.
This is in contrast to statically compiled code in which procedure calls are hardcoded.
It’s a form of late binding. Deciding what to do at the last possible moment
Just for fun, let’s compare the object-oriented definition of “message” with the definition were familiar with from another context.
Let’s compare it with sending a message through the mail.
When we send a message in the mail, we include everything the recipient might need to know in order to act on the message.
If they need information from a separate document, we summarize the relevant parts for them.
When we send a message to an object, we can include references directly to any other object we know about.
We can send the whole kitchen sink if we want to.
When we sent a message in the mail, we walk away from the mailbox and get on with our lives.
We may or may not receive a reply.
When we send a message to an object, it’s synchronous.
We freeze until that object is finished processing the message.
In Ruby, we know we will always get a reply in the form of a return value, even if it’s just nil.
When we send a message in the mail, if we send it in a language the recipient doesn’t understand, nothing happens to us.
When we send a message to an object that doesn’t understand it, our whole thread of execution blows up.
When we send a message in the mail, we know it might not reach anyone at all.
When we send a message to an object, we expect that it will either be handled, or we will see instant disaster.
Boy… These things are starting to sound not like messages at all.
But… They must be messages! Everything we’ve learned about objects says that the concept of messaging is central!
This is the big lie of object-oriented programming for the last 40 years:
We keep promising messages.
We keep saying we’re sending messages.
But we’re not.
Alan Kay envisioned objects as: being like biological cells and/or individual computers on a network, only able to communicate with messages.
But even Smalltalk, the language intended to embody OO principles, never fully implemented the messaging idea.
In some ways, the Smalltalk of the early 1970s was closer to this ideal than anything that came after.
Which means that every OO language has failed at delivering the central promise of OO.
But we keep talking and acting as if we are programming with real messages.
In fact, I’ve used that language over and over on this show!
This is why it’s so hard to learn and teach OOP
Because our words and the reality don’t match.
My goal here isn’t to destroy your faith in object-oriented programming.
But cognitive dissonance is dangerous. It rarely has positive outcomes.
And for decades we’ve been telling ourselves that we’re programming with messages, when we very obviously are not.
One theme I’ve returned to repeatedly on this show is that naming matters.
How we name things influences how we think about them.
When the naming is dissonant from the way those things work, our designs suffer.
I don’t have time in this little episode to talk about how to deal with this myth of messaging in modern OO languages.
But what I want to leave you with today is this:
It’s OK to question metaphors. Not just in your domain models, but in the tools you use everyday.
Even when everyone around you uses the metaphors as if they are fact.
And that’s all for today. As always, thanks for watching, and happy hacking!