Joachim writes:

> Well, my idea of OO starts with polymorphism. Late binding aka dynamic
> binding aka virtual method dispatch aka current Smalltalk-80 message
> send is the tool that implements that, so my position isn't that far
> from the Smalltalk one.

It is one thing to argue that someone else's nomenclature is inconsistent with one's own "idea of" what something else is -- it is another to state that the nomenclature is vapid or empty of meaning.  Joachim's argument, as we have seen here, really reduces to wordgames: "I define 'this' to mean that and this other thing.  Therefore your 'foo' is really just a this."  In fact, many arguments have already been offered and made, although they have been for the most part simply ignored by Joachim.
 > I don't see the reasoning behind Alan's claims. Is there a place where
> he goes into more detail on *why* he thinks that messaging is central?

And where is the reasoning behind Joachim's claims?  Indeed they began with a concession of the existence of differences and different concepts, and arguments that appear to reduce to no more than a restatement of the Turing equivalence of programming languages and a vague, but unsupported, argument concerning pedagogical advantage of thinking in terms of procedures.

To me, the centrality of messaging to Smalltalk to me becomes apparent just from studying the code of Smalltalk 80, particularly the metaclass, class and behavior infrastructure, and then considering just what is implemented in what.  It isn't necessary to have strong typing, even weak typing, indeed even classes, yet all of these are naturally implemented and understood under the aegis of messaging.

Of course, I note that this doesn't mean that messaging is "superior" to procedures as a programming paradigm -- that is, in fact, a far more complex argument.  Since logical operations can all be derived from NAND, NAND is in a sense more fundamental than AND, OR and NOT individually, but that fact does not by itself make reasoning in NAND better than using the derivative operations.  The fact that all computable functions can be expressed in combinators, Turing machines or another model doesn't mean they are superiod methods for coding.

However, there is little doubt to me that, despite the superficialities of turing equivalence, programming in combinators is fundamentally different from programming in the lambda calculus, which are fundamentally different from programming turing machines, which are fundamentally different from programming in C.