In Progress
Unit 1, Lesson 21
In Progress

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

Avdi here...

Southeast Ruby Conference announcement

The Message Myth

The Message Myth

...something we talk about a lot...

THE METHOD FALLACY

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.

Simple.

photo of Alan Kay

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.

Avdi with Sandi Metz

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!

when we send a message...

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

a letter in a mailbox

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.

chart - real and OOP messages

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.

chart compares concurrency

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.

chart compares bad content

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.

chart compares missing recipient

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!

THE BIG LIE

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.

photo of Alan Kay

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.

Kay himself has expressed some disappointment with the direction later Smalltalks took, saying: …they backslid towards Simula.

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!

hard to learn and teach OOP

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.

naming matters

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.

OK to question metaphors

I don’t have time in this little episode to talk about how to deal with this myth of messaging in modern OO languages.

You may have seen some of my preliminary thoughts on this subject already, in the episodes on Process Objects and the idea of “notify, don’t tell”.

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.

happy hacking

And that’s all for today. As always, thanks for watching, and happy hacking!

Responses