Alan Kay on the misunderstanding of OOP (1998)

Short Answer:

Calling a method is "Command and Control" where "command" is about getting a thing to do something that you want, and "control" is about preventing a thing from doing something that you don't want. In any case, you're running the process.

Message passing is about negotiating with something that is already in process. It turns out that this is the key to building scalable¹ systems (for all the usual reasons: enforcing loose coupling, abstraction, decentralization, etc.)

Longer Answer:

1. The actual powerful thing about a general-purpose computer is that it can simulate anything, including a "better" general-purpose computer (think about what Universal Turing Machine means).

2. Recursion is about making the part as powerful as the whole

Putting those two together leads to the original insight behind OOP: Why not build systems out of (scaled-down) computers!

So, in de-jure OOP, objects are supposed to be computers. Sometimes they are general-purpose computers (i.e. they contain an interpreter for a "Turing Complete" programming language), often times they are more limited special-purpose computers (e.g. functions, procedures, programs, etc.) . Crucially, the only way to interact with a computer/object is to send it input and receive output. It's completely up to the computer as to how to interpret the message (n.b. each object contains an interpreter). I like to think of OOP as being about scaling computer networks in both directions: scaling up gets you something like the Internet, scaling down can get you something like desktop publishing (I recall that Alan Kay said something like desktop publishing was really just about getting rid of the borders between apps).

While, in theory, method calling and message passing are equivalent, the problem with method calling is that it tends to limit you to building systems out of mere data structures that just happen to have all of the functions/procedures conveniently "nearby". Data structures are good if you want to make a process, but lame when you need to deal with one.

¹Scaling to me means that, with respect to some metric, there is a point at which the difference between the addition of part_n and the later addition of part_(n+1) becomes negligible. A part can be lots of different things: e.g. a user (metric is performance), an edit to the codebase (metric is pain), a new compute node in a network (metric is cost), etc...

(For the mathematically inclined, I think scaling is about making sure that the sequence of steps for building a system is Cauchy.)

The idea is to replace "calling a function" with "sending a message".

Traditionally a function call is fixed at compile time (with some exceptions such as function pointers). In C a function is just an address; if we want to call foo(), we must have that function available at address &foo. C++ added flexibility by allowing there to be multiple functions called foo() with and a set of vtables[1] that store the actual (C-style) address. Other variations exist, but all of these traditional styles map function calls to specific code that runs every time the function is called.

Message change all of that. Instead of vtables (or similar)

    obj = create_foo()

    # instead of calling foo's bar() function directly, e.g.
    foo_bar(obj)
    # or perhaps
    obj.bar()

... we send a message by name of the function we want to call to the object itself

    obj = create_foo()
    obj.send_message("bar")

    # if function args are needed, include them as an array
    obj.send_message("baz", [42, "quux"])

The idea is that while the message can be effectively the same as a function call, it doesn't have to be. In a proper OO language, this message sending is handled automagically by the syntax.

    # instead of handling the messages directly, e.g.
    obj.send_message("bar")
    # the language does that for you when you call
    obj.bar()
    # in some languages, these are equivalent

In many cases the "foo" class above will handle the message "bar" by running the appropriate function, but that isn't required. For example, in ruby when no function exists for a given message, the raw message is send to the #method_missing function.

    class Foo
      def method_missing(name, *args, &block)
        puts "#{self.inspect} I was sent message #{name.inspect} with args #{args.inspect}"
      end  
    end  

    >> obj = Foo.new
    => #
    >> obj.bar()
    # I was sent message :bar with args []
    => nil
    >> obj.any_name_we_want()
    # I was sent message :any_name_we_want with args []
    => nil
    >> obj.any_name_we_want("args", "are", "optional")
    # I was sent message :any_name_we_want with args ["args", "are", "optional"]

Thinking of "obj.method()" as a message instead of only a function is much more flexible.

[1] https://en.wikipedia.org/wiki/Virtual_method_table

"reifiable" = "able to be reified", where "to reify" means "to make something abstract concrete or real".

So, for example, Scheme's call/cc function reifies continuations- it take a continuation, an abstract control-flow concept, and turns it into a concrete object that you can pass around and manipulate in code. Therefore, continuations are reifiable in Scheme.

Breaking up a large functions into smaller functions isn't even (strictly speaking) functional decomposition because not every sub-function might be dependent on the previous function. "Extract function" is a kind of refactoring, but not refactoring itself.

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things."

What he's describing is the essence of Erlang.