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.
Messaging is a different concept from a "subroutine call with special first parameter." 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.
In general, a programming language concept *is* a thing which is different from the various ways it might be implemented in another programming language. I can think of monitors and CSS as an implementation of semaphores and streams as well, but to do so simply misses the point.
Besides, there's nothing special about subroutines either. Subroutines are just a couple of pushes onto a stack, a save of an instruction pointer, and a naked jump to some other code. And a while loop is just a special case of a goto. Why don't we just go back to coding purely with stores, loads, tests, logical ops and jumps? Aren't they all just the same thing?
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. Why don't we just express programming concepts in terms of Turing machine programming techniques?
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, even if true. But more important, expecting a new programming language to be capable of expressing a program that another one cannot is unreasonable -- at least theoretically speaking, they're all just flawed implementations of a Turing machine, capable of generating the same set of programs.
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." 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.
Edsger Dijkstra wasn't the first to note, although he was a principal exponent of the notion, that a notation and language colors and impacts the quality of our ability to conceive and implement solutions, and hence, the scope and quality of programs we are capable of creating given a fixed amount of programmer effort. Coding Smalltalk by thinking about it as C with some tweaks leads to frustration, not with the words, but with the mismataches between concepts. Coding Smalltalk qua Smalltalk is another thing entirely.
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.