smalltalk is generaly slow, and it has the same calling system as ruby.
in smalltalk, methods with the same name don't exist. every method on a object has an unique selector. The selector plays exactly the same role as the signature in java there is no difference on this aspect.
In what context? I've seen implementations of block encryption in Smalltalk that ran 3% faster than a DLL written in C! You wouldn't want to do heavy numerical integration utilizing lots of double precision floating point in Smalltalk, but for a lot of the sort of programming I do, several of the available Smalltalks are very snappy and responsive.
No, if I say "generaly" I don't give context, sorry. Don't answer to a rule of the thumb with anecdote.
More specificaly, on the same algorithm:
It's generaly slower than C/C++ (because of the method calls and the tagged arthmetics), unless you use the GC against the staticaly compiled code and slow allocator, but you need special cases. C/C++ "generaly" have faster method call.
It has few chances to be faster than java/.net who have the static types to get longer monomorphic specialization chains appart from corner cases, and generaly better GCs. And those can do deoptimization if the profile change, it's been a long time I left smalltalk, but the last time I checked VisualWorks couldn't.
In 11 years of Smalltalk IT consulting, I have never run up against the message send being a performance issue. For me, it's accessing the disk, the database, middleware, poor design with regards to network latency, or poor algorithm design.
I take your message, and change the "Smalltalk" by any other language, and I get a generic excuse for any language.
You can take a prominent ruby website, they will never admit ruby is slow, they cache everything everywhere to do the trick and then blame the algorithm too. Where on a JVM/.net platform the guys could recompute the same stuff 300/s without even needing to think about it, and still having the IO as a bottleneck. The same algorithm would'nt even be necessary in the first place.
BUT there are actually great differences in execution speed (or memory consumption) in languages for the same algorithm.
When your language pales in the benchmark, then you have various choices :
- dismiss the bench as not "real life"
- rewrite the algorithm to bank on the strength of your language (for smalltalk I would bet on the GC)
- count the lines of code (readability is not an objective metric so you can kill it for free). "Yeah but mine is more maintainable".
- admit that this is one weakness of your language and learn other languages for the day you'll need them.
I'm not dismissing your experience (far from it, actually I tend to like "slow languages" too).
I've worked with smalltalk and some friend did crazy stuff with it performance wise, I did crazy stuff in java too.
But
- smalltalk have a slow message dispatch time
- ruby have slow message dispatch and no real GC
- java have too big memory footprint and is too verbose
- O'caml and haskell have unreadable type error messages when you play with inference. And they are statically compiled.
- etc.
Maybe Apple will own the next disruptive platform (iPhone) and objective-C will have its day after all.
BTW: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
in smalltalk, methods with the same name don't exist. every method on a object has an unique selector. The selector plays exactly the same role as the signature in java there is no difference on this aspect.