Explanation of message sends for traditional programmers
You may be wondering how this all relates to the more traditional ways of programming. What "is" a message send in terms of a standard programming language? Well, it's both very traditional and novel. It is traditional in the mechanics of execution. The caller provides a set of parameter values for the message handler ((is "message handler" the right terminology?)). A message handler executes just like a subroutine: It accepts the parameter values in its formal parameters and does whatever it wants. It may have local variables, and it may return a value that will become the result of the call. What's not so traditional is the process that selects the message handler. ((Add a reference to the following topics here: (a) overriding, (b) dynamic binding, (c) polymorphism.))
Yeah, that old tradition of double dispatching, routine passing of lambdaesque functional parameters, and other things that make explaining:
String streamContents: [:s | foo process: s ]
in terms of function calls just cake. Or even better yet:
'Now here''s some Real Progress' displayProgressAt: Sensor cursorPoint from: 0 to: 10 during: [:bar | 1 to: 10 do: [:x | bar value: x. (Delay forMilliseconds: 500) wait]].
just simple to explain as a procedure call. And we routinely write such code in imperative language all the time, don't we?
With all due respect, while your points might be well taken, these types of operations took my breath away the first time I saw them, and I only really got it when I realized that a message send is a message send, and not a procedure call.
If we are discussing Turing equivalence, there is no dispute here. But if we are discussing pedagogy here, what Joachim suggests to me makes no sense at all. Perhaps as an initial pass, yes. But only for the sake of a quick bootstrapping, so on the second pass there can be a real understanding.