Erlang Doesn’t Fit The JVM

Post by 10ren » Fri, Apr 03, 2009, 4:13 PM UTC

10ren wrote: post #9

stcredzero wrote: post #3

At it’s heart the JVM is designed to run OO languages very efficiently. This is why languages like Ruby and Python are (mostly) easily ported to the platform... However, the JVM is less suited to running non-OO languages. Languages like Erlang, Haskell, and Scheme provide features, like tail recursion, closures, and continuations, which are not prominent in the mainstream OO world the JVM targets. They depart far eno…

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 su…

  void print(Object obj) {..}
  void print(String str) {..}

  Object a = "hello";
  print(a);

    print((String)a);

Post by stcredzero » Fri, Apr 03, 2009, 4:25 PM UTC

nraynaud wrote: post #17

10ren wrote: post #9

Earlier quoted context omitted.

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 su…

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.

Post by 10ren » Fri, Apr 03, 2009, 4:36 PM UTC

jimbokun wrote: post #24

nraynaud wrote: post #17

Earlier quoted context omitted.

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 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).

Post by johnm » Fri, Apr 03, 2009, 5:08 PM UTC

glymor wrote: post #37

johnm wrote: post #35

Earlier quoted context omitted.

You seem to be implying that one needs e.g., "green threads" to support huge numbers of "actors". That implication is false. Also, the only way that Erlang can support running on multiple actual hardware cores is, just as in Java "actor" implementations, to do an MxN mapping of actors to cores. Now, at one end of the spectrum there's the basic rule of thumb for each system to have O(number of cores) hardware threads…

You seem to be trying to make a big distinction between actors and green threads that I don't see. The MxN mapping stuff is a nice start but there a long way from there to the Erlang or Azul VM.

Post by 10ren » Fri, Apr 03, 2009, 6:02 PM UTC

jimbokun wrote: post #39

10ren wrote: post #36

Earlier quoted context omitted.

I didn't know that, thanks; I would have thought it was more C-like: 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... That's... a pretty cool combination.

It still makes me a little sad that C++ won out as the default "object oriented extension for C."