"Andrew C. Greenberg" wrote:
> 
> >This was one of my initial grudges against Smalltalk: Lots of new
> >words meaning just the same old stuff
> 
> . . .
> 
> >I concede there are important differences, and a different set of
> >concepts.
> 
> A crticial concession: Important differences and different concepts.
> This is *why* its a good idea to use different words.

Not if there are strong similarities. In such a case, the new
nomenclature should retain a similarity to the original concepts.
Heck, it would have helped if the Smalltalk literature had contained a
hint like "a message send is just like a subroutine call, except
that....". This would have helped me *tremendously*.

> Messaging is a different concept from a "subroutine call with special
> first parameter."

Right. I overlooked the dynamic dispatch involved (which is the central
concept; the implicit parameter is just a technical detail).

> Trying to think about oo programming in simple imperative concepts is
> one of the things that kept me from "getting it" with oodls initially,
> because I was always thinking about these things constructs by their
> analogues.

Hm. I'm doing OO programming based on the ADT concept, and quite
successful with that (I'm helping out at a customer site, and whenever
they have a design problem they ask me to solve it...).

> In general, a programming language concept *is* a thing which is
> different from the various ways it might be implemented in another
> programming language.  ...
> 
> Besides, there's nothing special about subroutines either. ...
> And a while loop is just a special case of a goto.  ...
> 
> And heck, every programming language concept is just an
> implementation of a state machine with a read/write movable head and
> a very large tape.  ...
> 
> All meaningful programming languages are capable of expressing any
> computable function.  This doesn't mean that all programming language
> concepts are "just the same thing."
> 
> Correspondence between those languages, in the sense that one might
> be implemented in another, isn't necessarily a useful observation,
> ...

Fully agreed. Programming language design is about human psychology, and
form matters greatly when the human mind is involved.
But that's not the point I was trying to make. My point was that the
Smalltalk presentation downplayed the similarities and emphasized the
differences. This mislead me into assuming differences where there were
none (and took up mental capacity that I'd have liked to spend for the
really interesting differences).

> Although one might attempt to reason about Smalltalk code by way of
> these analogues, I think it is losing to try to learn Smalltalk in
> this fashion, at least once you have gotten past the syntax and basic
> semantics stage.  Once I recognized that these *were* a different set
> of concepts with important differences, and started to think about
> them independently of the various possible ways to implement them, I
> found myself empowered in a way that surprised me.
> 
> [Mind you, I had the Smalltalk books on my Shelf since I bought them
> at graduate school in the early 80's -- I, too, simply looked at the
> books, tried to figure out how it was like Pascal, Algol, C and Lisp,
> and shelved it as "nothing new."

The concept of a class, together with dynamic dispatch, was really
novel. What was not novel was the flow of control once the system had
determined which routine to call. The Smalltalk literature just failed
to mention this, and I had to painstakingly find this out by tracing the
execution of the model VM in one of the Smalltalk books.

> Almost two decades later, after a fair amount of experience
> programming in OODLs, I found Squeak and ultimately learned something,
> I think, in part BECAUSE of the new nomenclature.

Well, I had to go the detour via C++ to find out what all this
nomenclature actually meant.

> Agreed, the words are distracting at first, but like all techniques
> learned, they are quickly absorbed once you set out to learn them,
> and rapidly become second nature.  Interestingly, as I found myself
> misusing the words in different ways initially, I learned that I was
> likewise misunderstanding the concepts.  Nomenclature is a VERY
> useful thing.  Agreed, I can code up Smalltalk methods in C,
> modelling them as subroutines.  But I no longer think of them in this
> way, and found Squeak a much nicer place to play once I did.

Unfortunately, special nomenclature creates unnecessary barriers.
Nomenclature should reflect similarities as well as differences. I know
this is different; and I know it is probably asking too much of the
researchers at their time to present not only a wholly new environment
but to also fully understand what's similar and what's dissimilar, and
in what ways a similarity is relevant or not. Still, I would have liked
to know that.

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