5 ms·

I get the impression that Smalltalk is very late-bound, whereas Java is sort of half-late-bound[1]. Late binding enables you to do pretty much anything. [1] Fo

by 10ren 18y ago

I get the impression that Smalltalk is very late-bound, whereas Java is sort of half-late-bound[1]. Late binding enables you to do pretty much anything. [1] For example: in Java, methods with the same name but different argument types ("overloaded") are statically bound; whereas in Smalltalk, they are dynamically bound. Java dynamically binds methods with the same name and same argument types that are defined in a subclass/implementation ("overridden"). Sounds like a performance tradeoff to me. (Is Smalltalk performance C-like or Python-like?)

nraynaud 18y ago
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.
- jimbokun 18y ago
  "in smalltalk, methods with the same name don't exist. every method on a object has an unique selector." Also true of Objective C (as many of you might already know).
  - 10ren 18y ago
    I didn't know that, thanks; I would have thought it was more C-like: http://en.wikipedia.org/wiki/Objective-C#Dynamic_typing http://en.wikipedia.org/wiki/Objective-C#Dynamic_typing And it seems that Objective-C performance is much closer to C than to python. http://www.omnigroup.com/mailman/archive/macosx-dev/2000-May/014124.html http://www.omnigroup.com/mailman/archive/macosx-dev/2000-May... That's... a pretty cool combination.
    - jimbokun 18y ago
      It still makes me a little sad that C++ won out as the default "object oriented extension for C."
      - 10ren 18y ago
        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_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
- stcredzero 18y ago
  smalltalk is generaly (sic) slow 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.
  - nraynaud 18y ago
    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.
    - stcredzero 18y ago
      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.
      - nraynaud 18y ago
        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. perfection doesn't exist, live with it.
jonhohle 18y ago
> For example: in Java, methods with the same name but different argument types ("overloaded") are statically bound; whereas in Smalltalk, they are dynamically bound. In Smalltalk you simply have messages. An object either responds to one or it doesn't, there's no concept of overloading. A method that looks the same, but has a different number of arguments is a different method. For example, in Java you might have a print method which takes a string, or a method with the same name which takes a format string and a variable number of replacements: String print(String s) { ... } String print(String s, Object... v) { ... } Same name, different signatures. In Smalltalk, those methods would have different names: print:f [...] print:f args:v [...] Where the names of the methods are print: and `print:args:` respectively. Smalltalk generally closer to Python than C in terms of performance.
deleted 18y ago
[deleted]
10ren 18y ago
It's not about methods with different signatures being being different methods, but about when they are bound. If a class has these methods: void print(Object obj) {..} void print(String str) {..} and we make the following invocation - which one gets called? The static, compile-time type of the invocation is Object and the dynamic, runtime class of the invocation is String. Which one will select the method? Object a = "hello"; print(a); In Java, the first method gets called (the one taking an Object argument). Because the compile time type of this invocation is Object, it is bound to the first method, regardless of the runtime class of a. Even if a is a String. It's the compile time type that selects the method, not the runtime class. To select the other method, we need to change the compile time type: print((String)a);

by 10ren 18y ago

nraynaud 18y ago

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.

jimbokun 18y ago
"in smalltalk, methods with the same name don't exist. every method on a object has an unique selector." Also true of Objective C (as many of you might already know).
- 10ren 18y ago
  I didn't know that, thanks; I would have thought it was more C-like: http://en.wikipedia.org/wiki/Objective-C#Dynamic_typing http://en.wikipedia.org/wiki/Objective-C#Dynamic_typing And it seems that Objective-C performance is much closer to C than to python. http://www.omnigroup.com/mailman/archive/macosx-dev/2000-May/014124.html http://www.omnigroup.com/mailman/archive/macosx-dev/2000-May... That's... a pretty cool combination.
  - jimbokun 18y ago
    It still makes me a little sad that C++ won out as the default "object oriented extension for C."
    - 10ren 18y ago
      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_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
stcredzero 18y ago
smalltalk is generaly (sic) slow 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.
- nraynaud 18y ago
  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.
  - stcredzero 18y ago
    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.
    - nraynaud 18y ago
      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. perfection doesn't exist, live with it.

jonhohle 18y ago

> For example: in Java, methods with the same name but different argument types ("overloaded") are statically bound; whereas in Smalltalk, they are dynamically bound. In Smalltalk you simply have messages. An object either responds to one or it doesn't, there's no concept of overloading. A method that looks the same, but has a different number of arguments is a different method. For example, in Java you might have a print method which takes a string, or a method with the same name which takes a format string and a variable number of replacements: String print(String s) { ... } String print(String s, Object... v) { ... } Same name, different signatures. In Smalltalk, those methods would have different names: print:f [...] print:f args:v [...] Where the names of the methods are print: and `print:args:` respectively. Smalltalk generally closer to Python than C in terms of performance.

deleted 18y ago

[deleted]

10ren 18y ago

It's not about methods with different signatures being being different methods, but about when they are bound. If a class has these methods: void print(Object obj) {..} void print(String str) {..} and we make the following invocation - which one gets called? The static, compile-time type of the invocation is Object and the dynamic, runtime class of the invocation is String. Which one will select the method? Object a = "hello"; print(a); In Java, the first method gets called (the one taking an Object argument). Because the compile time type of this invocation is Object, it is bound to the first method, regardless of the runtime class of a. Even if a is a String. It's the compile time type that selects the method, not the runtime class. To select the other method, we need to change the compile time type: print((String)a);