5 ms·

all of his points except for one are related to the jvm in general, which most people agree doesn't suck, and then when it is time to address java he just says

all of his points except for one are related to the jvm in general, which most people agree doesn't suck, and then when it is time to address java he just says "scala, clojure.. are great" Yes, thats the point. The JVM is well liked, but Java as a language is not, and I don't think he did much to change anyones opinion.

sklogic 12y ago
I do not agree that JVM does not suck. It sucks badly. No tail calls support, no (optional and confined) unsafe pointer arithmetics, no value types and a pathetic limit on a method size makes it an extremely shitty target for any language other than Java. All the existing languages running on top of JVM are very, very inefficient, or have to pay a horrible price for being able to run reasonably fast (crap like `recur` in Clojure, for example). edit: I suspect that none of the downvoters ever implemented a single compiler targeting JVM.
- dlubarov 12y ago
  > No tail calls support Is there a good reason for VMs to support TCO rather than having compilers perform it? > no (optional and confined) unsafe pointer arithmetics When do you want this? There's sun.misc.Unsafe#setMemory if you really need it. > no value types Might be added in JVMS 10 or some version thereafter. > a pathetic limit on a method size makes it an extremely shitty target for any language other than Java. True. > All the existing languages running on top of JVM are very, very inefficient, or have to pay a horrible price for being able to run reasonably fast (crap like `recur` in Clojure, for example). Fair enough, but it wasn't designed as a general purpose compilation target like llvm.
  - sklogic 12y ago
    > Is there a good reason for VMs to support TCO rather than having compilers perform it? Again this word! Proper tail calls handling is not an "optimisation". Optimisations are supposed to be optional, while tail calls handling makes a semantic difference. And, no, compilers cannot do it statically. You cannot statically resolve virtual calls, for example. Consider the following trivial case: `(define (f g x) (g x))` > When do you want this? There's sun.misc.Unsafe#setMemory if you really need it. Try implementing, say, an STG efficiently. Or even a WAM. > Might be added in JVMS 10 or some version thereafter. JVM may start to suck less at some point. But now it sucks. > but it wasn't designed as a general purpose compilation target like llvm. Exactly. And that's why it's inferior to the other VMs, which were designed with multiple source language semantics in mind. Including even CLR.
- pjmlp 12y ago
  > No tail calls support Due to the way JVM does bytecode verification. It will be fixed in future versions https://www.youtube.com/watch?v=2y5Pv4yN0b0 https://www.youtube.com/watch?v=2y5Pv4yN0b0 > no (optional and confined) unsafe pointer arithmetics www.docjar.com/docs/api/sun/misc/Unsafe.htm Will be replaced by an official API in Java 9. > no value types http://openjdk.java.net/jeps/169 http://openjdk.java.net/jeps/169 > pathetic limit on a method size makes it an extremely shitty target for any language other than Java. Java Virtual Machine
  - sklogic 12y ago
    > Due to the way JVM does bytecode verification. In CLR you can selectively switch off the verification. > www.docjar.com/docs/api/sun/misc/Unsafe.htm I do not want an inefficient API. I want a low level functionality which can be mapped efficiently to what the real hardware does. > http://openjdk.java.net/jeps/169 http://openjdk.java.net/jeps/169 > This work is not intended to change the Java Language Specification or JVM bytecode instruction set. Okay... It's not going to be anything useful. > Java Virtual Machine And that's exactly why it sucks. There are much more universal VMs out there.
    - pjmlp 12y ago
      > In CLR you can selectively switch off the verification. Why open the door to security exploits?! C derived languages are already enough. > I do not want an inefficient API. I want a low level functionality which can be mapped efficiently to what the real hardware does. Ever heard of intrinsics? Just because it looks like a method call, doesn't mean it is one. > Okay... It's not going to be anything useful. The final form is still ongoing work. > And that's exactly why it sucks. There are much more universal VMs out there Except for the CLR, I don't know any other. The universal VM has been pursuit since UNCOL was presented to the world.
      - sklogic 12y ago
        > Why open the door to security exploits?! Why limit your VM expressive power? Restrict only untrusted loadable modules, do whatever you want in the trusted realm. > C derived languages are already enough. Not nearly. You won't have a managed VM with fast run-time code generation with C. > Just because it looks like a method call, doesn't mean it is one. Problem with intrinsics is that the majority of your optimisation passed do not know anything about them. See LLVM as an unfortunate example. Most of the SIMD intrinsics are not even used in a simplest constant folding there. > Except for the CLR Bingo! CLR is better. Scrap JVM.
- wvenable 12y ago
  The JVM is just another example of worse-is-better. If you were to actually write a high performance JIT-able cross-platform VM that supports multiple languages, it wouldn't look anything like the JVM. The JVM worked well enough and a lot of companies put a lot of effort into it. But fundamentally, the design is "meh". It just gets the job done.
pjmlp 12y ago
Back when Java appeared it was a blessing. C compilers were between K&R C and ANSI C, writing portable code was #ifdef mess. C++ compilers were even worse than C ones. Each between their own interpretations of CFront, C++ ARM and ongoing work at ANSI. Outside UNIX world, no one cared about POSIX, which was in adoption phase anyway. So even across UNIX systems, #ifdef spaghetti code it was. Safe system programming languages like Ada, Modula-2, Modula-3, Oberon were failing to pick up steam with the enterprise adopting UNIX variants and its two main languages C and C++. Java brought sanity into writing portable code and better type safety. The initial versions were surely slow, but the adoption of JIT and AOT compilation across commercial JVMs helped to adopt it. As for the ivory towers that get written with Java, they were being written in code generators based in UML/OMT/Booch..., C, C++, Clipper and lots of 4GLs when it appeared. It is just an enterprise sin to write such type of software.
- edwinnathaniel 12y ago
  Any technology evolution will be like that. First System, Second System, Third System. Right now Java is slowly moving to the Third System (see the evolution from J2EE => JEE 5 => JEE 6 => JEE 7). Ditto with the mindset of Java developers of today.

sklogic 12y ago

I do not agree that JVM does not suck. It sucks badly. No tail calls support, no (optional and confined) unsafe pointer arithmetics, no value types and a pathetic limit on a method size makes it an extremely shitty target for any language other than Java. All the existing languages running on top of JVM are very, very inefficient, or have to pay a horrible price for being able to run reasonably fast (crap like `recur` in Clojure, for example). edit: I suspect that none of the downvoters ever implemented a single compiler targeting JVM.

dlubarov 12y ago
> No tail calls support Is there a good reason for VMs to support TCO rather than having compilers perform it? > no (optional and confined) unsafe pointer arithmetics When do you want this? There's sun.misc.Unsafe#setMemory if you really need it. > no value types Might be added in JVMS 10 or some version thereafter. > a pathetic limit on a method size makes it an extremely shitty target for any language other than Java. True. > All the existing languages running on top of JVM are very, very inefficient, or have to pay a horrible price for being able to run reasonably fast (crap like `recur` in Clojure, for example). Fair enough, but it wasn't designed as a general purpose compilation target like llvm.
- sklogic 12y ago
  > Is there a good reason for VMs to support TCO rather than having compilers perform it? Again this word! Proper tail calls handling is not an "optimisation". Optimisations are supposed to be optional, while tail calls handling makes a semantic difference. And, no, compilers cannot do it statically. You cannot statically resolve virtual calls, for example. Consider the following trivial case: `(define (f g x) (g x))` > When do you want this? There's sun.misc.Unsafe#setMemory if you really need it. Try implementing, say, an STG efficiently. Or even a WAM. > Might be added in JVMS 10 or some version thereafter. JVM may start to suck less at some point. But now it sucks. > but it wasn't designed as a general purpose compilation target like llvm. Exactly. And that's why it's inferior to the other VMs, which were designed with multiple source language semantics in mind. Including even CLR.
pjmlp 12y ago
> No tail calls support Due to the way JVM does bytecode verification. It will be fixed in future versions https://www.youtube.com/watch?v=2y5Pv4yN0b0 https://www.youtube.com/watch?v=2y5Pv4yN0b0 > no (optional and confined) unsafe pointer arithmetics www.docjar.com/docs/api/sun/misc/Unsafe.htm Will be replaced by an official API in Java 9. > no value types http://openjdk.java.net/jeps/169 http://openjdk.java.net/jeps/169 > pathetic limit on a method size makes it an extremely shitty target for any language other than Java. Java Virtual Machine
- sklogic 12y ago
  > Due to the way JVM does bytecode verification. In CLR you can selectively switch off the verification. > www.docjar.com/docs/api/sun/misc/Unsafe.htm I do not want an inefficient API. I want a low level functionality which can be mapped efficiently to what the real hardware does. > http://openjdk.java.net/jeps/169 http://openjdk.java.net/jeps/169 > This work is not intended to change the Java Language Specification or JVM bytecode instruction set. Okay... It's not going to be anything useful. > Java Virtual Machine And that's exactly why it sucks. There are much more universal VMs out there.
  - pjmlp 12y ago
    > In CLR you can selectively switch off the verification. Why open the door to security exploits?! C derived languages are already enough. > I do not want an inefficient API. I want a low level functionality which can be mapped efficiently to what the real hardware does. Ever heard of intrinsics? Just because it looks like a method call, doesn't mean it is one. > Okay... It's not going to be anything useful. The final form is still ongoing work. > And that's exactly why it sucks. There are much more universal VMs out there Except for the CLR, I don't know any other. The universal VM has been pursuit since UNCOL was presented to the world.
    - sklogic 12y ago
      > Why open the door to security exploits?! Why limit your VM expressive power? Restrict only untrusted loadable modules, do whatever you want in the trusted realm. > C derived languages are already enough. Not nearly. You won't have a managed VM with fast run-time code generation with C. > Just because it looks like a method call, doesn't mean it is one. Problem with intrinsics is that the majority of your optimisation passed do not know anything about them. See LLVM as an unfortunate example. Most of the SIMD intrinsics are not even used in a simplest constant folding there. > Except for the CLR Bingo! CLR is better. Scrap JVM.
wvenable 12y ago
The JVM is just another example of worse-is-better. If you were to actually write a high performance JIT-able cross-platform VM that supports multiple languages, it wouldn't look anything like the JVM. The JVM worked well enough and a lot of companies put a lot of effort into it. But fundamentally, the design is "meh". It just gets the job done.

pjmlp 12y ago

Back when Java appeared it was a blessing. C compilers were between K&R C and ANSI C, writing portable code was #ifdef mess. C++ compilers were even worse than C ones. Each between their own interpretations of CFront, C++ ARM and ongoing work at ANSI. Outside UNIX world, no one cared about POSIX, which was in adoption phase anyway. So even across UNIX systems, #ifdef spaghetti code it was. Safe system programming languages like Ada, Modula-2, Modula-3, Oberon were failing to pick up steam with the enterprise adopting UNIX variants and its two main languages C and C++. Java brought sanity into writing portable code and better type safety. The initial versions were surely slow, but the adoption of JIT and AOT compilation across commercial JVMs helped to adopt it. As for the ivory towers that get written with Java, they were being written in code generators based in UML/OMT/Booch..., C, C++, Clipper and lots of 4GLs when it appeared. It is just an enterprise sin to write such type of software.

edwinnathaniel 12y ago
Any technology evolution will be like that. First System, Second System, Third System. Right now Java is slowly moving to the Third System (see the evolution from J2EE => JEE 5 => JEE 6 => JEE 7). Ditto with the mindset of Java developers of today.