
Alan Kay on Messaging (1998) - stesch
http://c2.com/cgi/wiki?AlanKayOnMessaging
======
parasubvert
I remember this being posted in 1998, as people were debating the surge of
Java relative to C++ or Smalltalk.

These were the twilight days where C and assembly were the only language Real
Programmers used, Perl and Tcl or any scripting/interpreted language were
considered toys for sysops and never meant for production, OO was treated with
deep suspicion, and functional languages were considered crazy talk. I
remember people in my company saying a particular C++ replacement program my
colleague wrote was "too OO" and would execute 10x slower than required (when
it was 2x faster than the legacy).

Point is, a lot of what Kay says is obvious now, but it wasn't in the 90s, and
it REALLY wasn't in the 70s.

One sees new things every time one reads this. For example, Kay comes out as a
supporter (of sorts) to functional programming principles by calling
assignments (mutable state) a metalevel change.

~~~
zak_mc_kracken
> Point is, a lot of what Kay says is obvious now

It's obvious because he's not saying much, besides trying to redefine
"function call" with "message passing" so that it makes Smalltalk look better.

~~~
cconroy
In a function call the arguments are applied to the function after being
evaluated (LISP's apply).

In Message Passing a message (which is just another object) is _sent_ to the
receiver object.

The crucial difference is in a function call the the function is already bound
when the args are sent. With message passing the args are sent to the receiver
object which can handle them there or up its superclass hierarchy -- with the
ability to handle messages it does not recognize too after exhausting the
superclass hierarchy.

The smalltalk blue book has the VM implementation of message sending which is
very straight forward.

~~~
pacala
The distinction is mostly of historical relevance, being relevant to the time
where function names were bound at link time in mainstream systems. In a
modern system, Java/C#/Python/Javascript/..., we take for granted that
function names are bound at runtime. "Calling a function into a module/object"
means having the module resolve the function name, then execute the function.
Messaging is an implementation detail, just like vtables are another way to
implement this idea.

~~~
jacquesm
That's a fundamental difference which allows a whole pile of stuff to happen
that otherwise would be either hard or impossible.

Messaging versus parameter passing is an entirely different beast that for
instance (but not limited to) allows you to send the message to another
process for handling and that other process could (theoretically) live on
another host.

Smalltalk has a lot of nifty stuff under the hood and never managed to realize
even a fraction of its potential due to all kinds of factors none of which
have anything to do with the core ideas of the language.

Message passing is a game changer, and is in no way equivalent or comparable
to calling functions with a bunch of parameters though implementing that using
message passing is trivial.

The runtime binding aspect is only one detail, and not the most important one
at that.

~~~
dang
> The runtime binding aspect is only one detail, and not the most important
> one at that.

What are some of the others?

~~~
jacquesm
\- messages are asynchronous, function calls are (pretty much by definition)
synchronous

\- messages do not require a reply (but function calls typically do expect a
result)

\- messages are a lot more secure in that the credentials of the sender can be
inspected by the recipient which can be walled off in a different area of
memory or even on a different machine

\- message based architectures are easier to scale than function call based
architectures

\- message based architectures tend to have higher overhead per message than a
function call with the same payload and return value

\- message based architectures tend to lend themselves to soft real time
approaches better than monolithic threaded software using functions as the
main means of passing data around

\- message based architectures tend to be more reliable

\- message based architectures typically allow for things that are next to
impossible in a function based environment, such as process migration and load
balancing as well as coping with hardware failures

\- message based architectures are easier to debug (by far) than large systems
built up using nothing but function calls.

\- message based systems tend to be a bit slower, especially if they take the
message idea all the way to the lowest levels of the language (such as in
smalltalk).

Really, the differences are legion. I've built some stuff using message
passing that I would simply have had absolutely no way of getting production
ready if not for using a message based approach, it allows you to limit the
scope to the processing of a single message at all time rather than to have to
model the entire call stack in your head to keep track of what you're doing
and why. As an abstraction model it is extremely powerful and for that reason
alone I'd happily advise anybody that has not yet played with an environment
like that to give it a whirl.

It's not a passe-partout but it certainly is a powerful tool in the toolbox.

~~~
Jare
> message based architectures are easier to debug (by far)

This is the opposite of my experience, mainly because of the lack of proper
call stacks, it is very hard to inspect the reason the values in a message are
what they are. Can you elaborate?

~~~
jacquesm
That's interesting. I guess this boils down to how far from the point of
origin a bug originates.

In a message based system that should be at most one step away from where you
find the bad value. If it is more than one step away that's more of an
architectural issue, it probably means that you are sending your messages
first to some kind of hub which then passes it on to the actual recipient so
you lose the point of origin information.

A message that gets passed on untransformed from a module that does not
realize the data is corrupted is a missed chance for an integrity check and a
subsequent crash.

Smalltalk does a half decent job at integrating the 'debugger' with the
runtime environment (they're so tightly integrated it's hard to tell where one
starts and the other one ends) and allows you to see fairly detailed traces of
what happened to which parameter along the way, it's as detailed as any call
stack dump.

Erlang has a 'let it crash' policy (see Joe Armstrong's excellent paper) which
tries to enforce the point of origin and the subsequent crash happen as close
to each other as possible (and provides a whole range of mechanisms to deal
with the fall-out).

A 30 level call-stack like say Java would produce simply doesn't happen in
those environments. Though if you programmed in a 'Java' style in say 'erlang'
then you could generate one and it would make your life much harder.

~~~
Jare
No hehe, my experience is mostly C++ PC and console games, so a) let it crash
is not viable, and b) performance precludes performing extensive validation (a
debuggable but unresponsive game is not viable).

In games, messaging troubles are usually related to systems like character
behaviour and AI that deal with multiple complex entities responding to the
world state and interacting with each other. It's rarely a case of corrupt
data and null pointers (those are easier): physically valid yet logically
incorrect or unexpected data.

~~~
jacquesm
I think you're missing out on something, have a read and see if maybe 'let it
crash' is more than you think it is:

[http://web.archive.org/web/20090430014122/http://nplus1.org/...](http://web.archive.org/web/20090430014122/http://nplus1.org/articles/a-crash-
course-in-failure/)

[https://mazenharake.wordpress.com/2009/09/14/let-it-crash-
th...](https://mazenharake.wordpress.com/2009/09/14/let-it-crash-the-right-
way/)

------
delish
Just a little comment: Kay's mentioning various meta-things reminds me that I
have The Art of the Metaobject Protocol (which Kay called "the best OOP book
in ten years," and I should read it.

And another little comment as regards Kay's "complaining" that Smalltalk had
become "something to be learned": I very much failed to learn computer science
from high school Java, where classes, methods, encapsulation etc were treated
as things-to-be-learned. I didn't know that I /could/ care about how they were
put in place or why.

If I had been taught that everything in a meta-system can be changed when you
structure your changes, I would have been a happier camper--motivated by
autonomy and purpose.

~~~
parasubvert
The art of the meta object protocol was good, it basically was a well-written
code commentary for how to build an advanced OO meta system (CLOS) for LISP.
CLOS was a bit of a dream language, I'd say Scala is perhaps the closest
practical language in terms of ideas.

Interestingly, this work led Gregor Kiczales & team to create Aspect Oriented
Programming - a subset of his metasystem - which became somewhat popular with
Java and the Spring framework's use of AspectJ.

[http://en.m.wikipedia.org/wiki/Aspect-
oriented_programming](http://en.m.wikipedia.org/wiki/Aspect-
oriented_programming)

As an aside, I found in college (let along high school!) that students have
almost anti-philosophical learning objectives. The SICP approach of teaching
computer science from the metasystem up with Scheme (and then possibly moving
on to CLOS/Lisp) was near-universally hated among my peers (1996-2002) - most
wanted a practical language they could "get a job" with. I believe MIT first
year CS switched to Python in part to deal with this resistance.

~~~
mbrock
What makes Scala more "practical" than Common Lisp, other than incidental
matters of library support on the JVM?

~~~
parasubvert
That, and the dearth of people that know CLOS, or are able and WANT to learn
CLOS. "Design by resume" surrounds us.

------
Pharoer_
Messages are inherently decoupled from the methods they invoke, unlike
function calls or function pointers. For example, in Smalltalk you can rewrite
this:

    
    
      dictionary at: aKey put: aValue
    

to:

    
    
      dictionary perform: #at:put: with: aKey with: aValue
    

where #at:put: is just a Lisp-style symbol object, an identifier, and
perform:with:with: sends a message to the receiver with the first argument as
the selector and second and third as its arguments. As one example, this
allows you to have a button object that you configure to send some message
selector to some object when clicked. Obviously, you can accomplish this
equally well with anonymous functions, and since Smalltalk has probably the
most concise syntax for anonymous functions (just pairs of "[" and "]"), they
are often used instead.

Speaking of anonymous functions and OO, it's bizarre to see FP zealots cite
their gradual introduction into mainstream OO languages as proof of some move
away from OOP and towards FP, when Smalltalk has had them since 1972 and uses
them much more extensively than many "pure" functional languages do (though
admittedly in part due to currying and partial application as in Haskell
subsuming many of their use cases).

------
pacala
> The big idea is "messaging" \- that is what the kernal of Smalltalk/Squeak
> is all about (and it's something that was never quite completed in our Xerox
> PARC phase). The Japanese have a small word - ma - for "that which is in
> between" \- perhaps the nearest English equivalent is "interstitial". The
> key in making great and growable systems is much more to design how its
> modules communicate rather than what their internal properties and behaviors
> should be. Think of the internet - to live, it (a) has to allow many
> different kinds of ideas and realizations that are beyond any single
> standard and (b) to allow varying degrees of safe interoperability between
> these ideas.

What is the difference between "messaging" and "function call"?

"messaging" data into a module = call a function with the data as arguments.

"messaging" data out of a module = package the data as the return of the
function.

~~~
wpietri
You should take a look at the Reactive Manifesto [1] and the actor model [2].
My own personal and non-expert take is that message orientation is about the
wholeness of the actors that pass messages. "Would you care for a drink?" is
message oriented. Whereas many systems built on function calls are more like
you jabbing me in the butt with a syringe filled with 20 ccs of alcohol.

[1] [http://www.reactivemanifesto.org/](http://www.reactivemanifesto.org/)

[2] [http://www.infoq.com/news/2014/10/intro-actor-
model](http://www.infoq.com/news/2014/10/intro-actor-model)

------
lazydon
If the big idea was messaging and not objects, I'm curious to know how did we
end up in this primarily object oriented world. Especially, when its founding
father didn't had that intention as he says: ""I invented the term object-
oriented, and I can tell you that C++ wasn't what I had in mind".

I have a guess from following quote: "This was why I complained at the last
OOPSLA that - whereas at PARC we changed Smalltalk constantly, treating it
always as a work in progress - when ST hit the larger world, it was pretty
much taken as "something just to be learned", as though it were Pascal or
Algol." -

There were people in hurry to make something with whatever theoretical basis
there was instead of further refining the original concept. Probably, that's
where it took the wrong turn.

~~~
parasubvert
Refining a language or programming paradigm requires a philosophical or
scientific bent. Not much money in that. Most people just want to get a job
done and go home at 5pm.

Edit: Bright side, I think polyglot programming is more popular now than ever
in history. In the past you learned one language and that was 20 years of your
career before you went into management. Your identity was wrapped up in being
a "VB person", "C", "COBOL", or "Java/C# person" or "Rubyist" .

There still is language identity politics but I think Ruby might have been the
last of the One True Religions, now the frontier is all over the place between
Python, Ruby, Node, Java, Golang, c#, etc.

~~~
coliveira
I think it is a perversion of computer science that we think ourselves as
users of languages, instead of creators of languages. Especially because it is
not hard to create a language these days -- we know much more and have better
tools than people 30 years ago. Many of the problems that we consider uber-
complicated could be relatively easily solved by creating appropriate problem-
specific languages: consider web programming, data mining, etc.

~~~
parasubvert
I'm with you. But it becomes a skills and NIH-attitude issue at scale, where
the evolution of science is less of a concern than treating the science as
constant for an engineering project.

I've seen lovely crafted DSLs that were deemed unmaintainable when the creator
moved on, and management cursed the use of them if they weren't already a
popular OSS project.

~~~
coliveira
The reason is that DSLs are just viewed as "another" burdensome language,
instead of a design for codified problem-specific knowledge. A DSL should
evolve as we evolve our understanding of the problem. Think about successful
DSLs like Mathematica, for example.

------
stretchwithme
In case anyone is looking for the video of the keynote Kay gave before this
post. There's a dead link to it at the bottom of the page.

    
    
      https://www.youtube.com/watch?v=oKg1hTOQXoY

