"Andrew C. Greenberg" wrote:
> 
> 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.

Such things are standard issue in functional programming (which does not
claim to have a special "message passing" thing).
Yes, it is very special. And it is not common in imperative programming.
But it doesn't warrant a new name for things today; mainstream
terminology is fully capable of describing these features. (I'm well
aware that mainstream terminology in the 80ies wasn't there 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.

Hm. I did exactly this type of things in my student days with a Lisp
system. It took my breath away, but it was entirely nonpolymorphic.

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

Ah well, we all have our different learning histories and habits. I
understand the stuff better if I see how new stuff relates to known
stuff. I was under the impression that this would benefit everybody, but
it's obvious that I don't meet consensus here.

Regards,
Joachim
-- 
Please don't send unsolicited ads.