On double dispatching:

> Such things are standard issue in functional programming > (which does not
> claim to have a special "message passing" thing).

I haven't forgotten the question.  Please offer a straightforward account of double dispatching in terms of subroutines.

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

As Professor Johnson noted, "messaging" isn't a new name.  As far as the "fully capable," what do you mean?  Fully capable, in the sense of giving an operative account?  Isn't that closer to "technically sufficient to describe?"  In the sense of being a sound basis for programming in the language?  Once again, I'm not sure I have seen any fair account of that description for the particular examples given.

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

Fully capable means explaining not "exactly this type of thing" but "exactly the thing itself."  Please explain in terms of functions exactly how this is done.  Once again.  How can a procedural view of the world lead you to writing this code?

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

Joachim, its more that many of us have all seen and written Smalltalk VM's, know therefore how to write in C, but choose to use the underlying system and leverage arising from using Squeak.  There *is* a gestalt which is why we write some things in Squeak, rather than the underlying system in which we compiled it.  Understanding how it works *does* lend some insight, but it also misses the point.  I can do things in Squeak far faster, more simply and more clearly than I can do in the C-compiler from which I built the VM on which it is running.  I have powerful (probably more powerful) libraries from which I can rely in the underlying system, but I still use Squeak therefor.

Part of the reason is that I can trivially articulate what I need to say in Squeak in a way I cannot in C.  Accordingly, it doesn't surprise me to say that I was helped by "getting past" the simple nomenclature of the C world, and adopting the language of Smalltalk.

Dijkstra writes a lot about how notation affects how we think about our programs.  If I had to focus on thinking how my message calls are resolved in operative terms, I would lose much of the leverage I now have in hacking Squeak.  This is much the same as how if we had to hand-execute every loop we wrote (since that is how we understand how it works), we would never get the full benefit of the programming construct and wouldn't be able to code as well.

I find the Smalltalk nomenclature more aptly characterizes the operation of Smalltalk than Joachim's "fully descriptive" alternative, in a manner that I can use.  That is my point.