Messaging vs. subroutines -- This is silly

Joachim Durchholz joachim.durchholz at
Fri May 21 20:00:51 UTC 1999

"Andrew C. Greenberg" wrote:
> Joachim writes:
> >A method is a subroutine.
> >A message send is a plymorphic selection, followed by a subroutine
> >call to the appropriate method.
> We've heard this before.

Sorry for repeating myself.
I was trying to clarify a point to Randall.

> Even taking this as true, it proves the point at least from a logical
> as well as a pedagogical point of view. Logically, its sophistry to
> assert that anything comprising two distinct substantive parts, can be
> "just the same as" only one of its parts?  Pedagogically, its
> important to understand a composite concept, not only as defined by
> its respective parts, but also as the gestalt that is sometimes more
> than the sum of its parts.

Fully agreed.

The thing that I'm storming against is that Smalltalk literature tends
to present message sends as an atomic concept, not as a composite one.
This hampers understanding for those who already know a component.

Besides, those who didn't have exposure to the component concepts will
continue to think that message sends are a monolithic concept, and be
unable to follow if people from a different background start talking
about such a component. They'll just assume that the outsider got it
wrong... it's the same sort of mistake as saying that Smalltalk is
lacking static typing.

That the sum is more than its parts is also true. I don't say that
message sending is "nothing more" than the two components that I have
listed - conceptually. I think message sends should be explained both
ways: As a composite of more primitive operations, and as a new whole
with new applications that the primitives alone cannot accomplish.

As I wrote elsewhere, I think both views are valuable. The more views of
an operation you have, the more you can vary its use. And that's
extremely useful if you have a design problem to solve.

Please don't send unsolicited ads.

More information about the Squeak-dev mailing list