>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.