"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