"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