3 ms·

But there IS a reason. Java is a far more statically typed language than Javascript. That enables certain optimizations that will simply never be viable in Java

by zmmmmm 12y ago

But there IS a reason. Java is a far more statically typed language than Javascript. That enables certain optimizations that will simply never be viable in Javascript, at least as it it is generally used. You can make an argument that this isn't the case for FFOS for some special reasons, but I don't think you can legitimately make a claim that there's "no reason" and leave it at that.

tomp 12y ago
Actually, no. Java is a far more primitive language than JS, and it's specification require it to consume large amounts of memory. In Java, all objects need to have at least one additional field so that they can be used for synchronization. Most JS engines, on the other hand, support tagging (floats/doubles/ints are stored unboxed). In Java, everything needs to be statically typed, and every object needs a class. If you want to make a first-class function, you need a classfile, a class, and an actual full-blown object for that function. In JavaScript (and other languages supporting first-class functions), closures can be optimized and represented by a single "closure" class, which has an existential type (the tuple of types of closed-over variables) and which is guaranteed to be correct (sound) by construction. Modern JIT engines work very very well for the majority of "nice" (strict) dynamically-typed code. Where you lose is (1) numerics (where Java sucks as well, no vectorization - JavaScript is probably better here, with WebGL) and (2) non-polymorphic function calls (which are quite rare in Java as well). For polymorphic functions, polymorphic inline caches perform very well, probably not much worse than virtual/interface calls.
- oldmanjay 12y ago
  >If you want to make a first-class function, you need a classfile, a class, and an actual full-blown object for that function. this isn't wholly true as of java 8. dynamic invocation is used to implement the new lambda facility.
  - oldmanjay 12y ago
    replying to myself to add info, in case anyone stumbles across this. I was only half correct - the current implementation does generate a dynamic invocation in bytecode, but the bootstrap framework that binds the call site ends up generating a class at runtime to "seal the deal" as it were. I hadn't read through all the details before now. one source with many links: http://www.takipiblog.com/compiling-lambda-expressions-scala-vs-java-8/ http://www.takipiblog.com/compiling-lambda-expressions-scala...

by zmmmmm 12y ago

tomp 12y ago

Actually, no. Java is a far more primitive language than JS, and it's specification require it to consume large amounts of memory. In Java, all objects need to have at least one additional field so that they can be used for synchronization. Most JS engines, on the other hand, support tagging (floats/doubles/ints are stored unboxed). In Java, everything needs to be statically typed, and every object needs a class. If you want to make a first-class function, you need a classfile, a class, and an actual full-blown object for that function. In JavaScript (and other languages supporting first-class functions), closures can be optimized and represented by a single "closure" class, which has an existential type (the tuple of types of closed-over variables) and which is guaranteed to be correct (sound) by construction. Modern JIT engines work very very well for the majority of "nice" (strict) dynamically-typed code. Where you lose is (1) numerics (where Java sucks as well, no vectorization - JavaScript is probably better here, with WebGL) and (2) non-polymorphic function calls (which are quite rare in Java as well). For polymorphic functions, polymorphic inline caches perform very well, probably not much worse than virtual/interface calls.

oldmanjay 12y ago
>If you want to make a first-class function, you need a classfile, a class, and an actual full-blown object for that function. this isn't wholly true as of java 8. dynamic invocation is used to implement the new lambda facility.
- oldmanjay 12y ago
  replying to myself to add info, in case anyone stumbles across this. I was only half correct - the current implementation does generate a dynamic invocation in bytecode, but the bootstrap framework that binds the call site ends up generating a class at runtime to "seal the deal" as it were. I hadn't read through all the details before now. one source with many links: http://www.takipiblog.com/compiling-lambda-expressions-scala-vs-java-8/ http://www.takipiblog.com/compiling-lambda-expressions-scala...