11–20 of 51 posts
I feel your pain with java serialization. The fact that you cant serialize exceptions to notify systems connected to a JVM that something blew up is just insane. All objects should be able to be serialized (in binary) from one system to another as long as JVM versions and class libraries match... end of story.
the tail call is a bytecode security problem. Looks like this problem has been solved and will be merged.
Isn't LLVM a more interesting universal machine to target anyway?
I wonder if I can invest on it because they will close the gap, or if they are just playing catchup with gcc, in which case there is no future for GC languages.
Erlang's VM is unmatched scaling above 16+ cores (for example process migration http://unlimitednovelty.com/2009/01/cutting-edge-of-vm-desig... ) this is something that the java vm hasn't even begun to look at.
Check http://blogs.azulsystems.com/cliff/ for really impressive work on jvm that works on 800+ cores ... oh yes, and you have constant time garbage collection.
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…
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.
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…
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) { ... }
In Smalltalk, those methods would have different names:
print:f [...]
print:f args:v [...]
Smalltalk generally closer to Python than C in terms of performance.
Earlier quoted context omitted.
Isn't part of the reason for targeting the JVM the ton of libraries you get for free?
How many of them fit idiomatically into the language you choose to use on the JVM?
From their docs:
(doto (new java.util.HashMap) (.put "a" 1) (.put "b" 2))
(.. System (getProperties) (get "os.name"))Erlang's VM is unmatched scaling above 16+ cores (for example process migration http://unlimitednovelty.com/2009/01/cutting-edge-of-vm-desig... ) this is something that the java vm hasn't even begun to look at.
That is untrue. Check http://blogs.azulsystems.com/cliff/ for really impressive work on jvm that works on 800+ cores ... oh yes, and you have constant time garbage collection.
And from your link "we have a lite microkernel style OS; we can easily handle 100K runnable threads" it's not the VM that's handling it.