4 ms·

Why does it matter to you? I mean, I know why I find it to be a positive: implementing a runtime is a vast and complex task, and doing it well is way too expens

by jwr 7y ago

Why does it matter to you? I mean, I know why I find it to be a positive: implementing a runtime is a vast and complex task, and doing it well is way too expensive for most projects (see for example the problems Python has had over the years with the global interpreter lock). If you can use a runtime with gazillions of man-hours invested into making it better, and get easy access to bazillions of native libraries, why not?

tdbgamer 7y ago
While I agree with you that the JVM is great, I think most people that don't like it really just hate Oracle. It's not really a technical argument as much as it is philosophical. I don't really care either way, but I can see why people would mistrust Oracle knowing their history.
- pjmlp 7y ago
  Yeah, because Sun never did wrong stuff and everyone was queuing up to buy it.
- ilikehurdles 7y ago
  I switched to openJDK implementations after JDK 8 and lately that seems to be the way the entire community is going, due to Oracle’s new licensing restrictions.
- jwr 7y ago
  I understand the sentiment, Oracle is a terrible company and I don't like it either. But at this point we have the OpenJDK and you can use the JVM without caring about Oracle at all.
- balfirevic 7y ago
  I remember seeing complaints about Clojure running on JVM even before Oracle bought Sun.
Veedrac 7y ago
> If you can use a runtime with gazillions of man-hours invested into making it better, and get easy access to bazillions of native libraries, why not? Note that this same comment argues for Electron.
- didibus 7y ago
  Yup, and there's ClojureScript for that one :p
ken 7y ago
As a Clojure user, I've only fairly recently moved from "the JVM is a boat-anchor on this design" to "the JVM is not an advantage, but it's not so terrible, either". So I'll answer. > a runtime with gazillions of man-hours invested into making it better, "Man-hours" are such a non-measure of productivity that the classic software engineering book in our industry has a title that declares them a "myth". The JVM turns out to work fine for functional languages like Clojure, but from my perspective, there's no inherent reason it necessarily should. There's a huge impedance mismatch, as Clojure is not much like Java, and the priorities are completely different. Bragging that some C program has had a gazillion people work on it means either it has a gazillion special cases (not an advantage), or it has a gazillion bugs fixed (most of which were probably caused by using a low-level unsafe language like C in the first place). Yay but ouch. (Implementing a new programming language is also typically a vast and complex task, but Clojure has an impressively small number of contributors. When you think through the design first and focus on simplicity, you don't need a gazillion special cases.) Coming from the Common Lisp world, there's gobs of pure-Lisp programs and libraries I've used which are absolutely a joy to work with, at every level. They don't need many contributors because the code is drastically shorter and simpler. There's lots of Lisp libraries with only a dozen commits, which haven't been touched in years, and a version number way less than 1.0, which work great. That's all they need. > and get easy access to bazillions of native libraries, I can see why these can be important when bootstrapping a new language environment, but in practice, beyond version 1.0, I really don't care about them at all. The interfaces I use from Clojure tend to be "return a function", or even "return a function which returns a function". No Java library is designed like this. They're designed around mutable classes, which makes them pretty awkward to use from a functional language. I'll go find a 100-line native Clojure library instead, and by now, there's 100-line native Clojure libraries for almost everything I need. For another example, the numeric tower is part of the core of Common Lisp, so it's usable from anywhere. BigInteger is a library in Java, and Java still doesn't seem to have rational or complex types, so Clojure does the best it can, but anything beyond fixnum arithmetic is basically opt-in, and almost no libraries use it. Debugging is even worse, because while there are a million google hits for "java library X", and a thousand hits for "lisp library Y", there's often almost no hits for "java library X with clojure". I have to mentally translate the Java X solutions into Clojure, and figure out any JVM/Clojure interop issues myself from first principles. That said, Clojure overall works great in practice, and for the most part you can ignore the JVM and its issues. But any time I'm forced to become aware that the JVM exists, my life ends up being worse than the equivalent scenario in the turtles-all-the-way-down world of other Lisps.

by jwr 7y ago

tdbgamer 7y ago

While I agree with you that the JVM is great, I think most people that don't like it really just hate Oracle. It's not really a technical argument as much as it is philosophical. I don't really care either way, but I can see why people would mistrust Oracle knowing their history.

pjmlp 7y ago
Yeah, because Sun never did wrong stuff and everyone was queuing up to buy it.
ilikehurdles 7y ago
I switched to openJDK implementations after JDK 8 and lately that seems to be the way the entire community is going, due to Oracle’s new licensing restrictions.
jwr 7y ago
I understand the sentiment, Oracle is a terrible company and I don't like it either. But at this point we have the OpenJDK and you can use the JVM without caring about Oracle at all.
balfirevic 7y ago
I remember seeing complaints about Clojure running on JVM even before Oracle bought Sun.

Veedrac 7y ago

> If you can use a runtime with gazillions of man-hours invested into making it better, and get easy access to bazillions of native libraries, why not? Note that this same comment argues for Electron.

didibus 7y ago
Yup, and there's ClojureScript for that one :p

ken 7y ago

As a Clojure user, I've only fairly recently moved from "the JVM is a boat-anchor on this design" to "the JVM is not an advantage, but it's not so terrible, either". So I'll answer. > a runtime with gazillions of man-hours invested into making it better, "Man-hours" are such a non-measure of productivity that the classic software engineering book in our industry has a title that declares them a "myth". The JVM turns out to work fine for functional languages like Clojure, but from my perspective, there's no inherent reason it necessarily should. There's a huge impedance mismatch, as Clojure is not much like Java, and the priorities are completely different. Bragging that some C program has had a gazillion people work on it means either it has a gazillion special cases (not an advantage), or it has a gazillion bugs fixed (most of which were probably caused by using a low-level unsafe language like C in the first place). Yay but ouch. (Implementing a new programming language is also typically a vast and complex task, but Clojure has an impressively small number of contributors. When you think through the design first and focus on simplicity, you don't need a gazillion special cases.) Coming from the Common Lisp world, there's gobs of pure-Lisp programs and libraries I've used which are absolutely a joy to work with, at every level. They don't need many contributors because the code is drastically shorter and simpler. There's lots of Lisp libraries with only a dozen commits, which haven't been touched in years, and a version number way less than 1.0, which work great. That's all they need. > and get easy access to bazillions of native libraries, I can see why these can be important when bootstrapping a new language environment, but in practice, beyond version 1.0, I really don't care about them at all. The interfaces I use from Clojure tend to be "return a function", or even "return a function which returns a function". No Java library is designed like this. They're designed around mutable classes, which makes them pretty awkward to use from a functional language. I'll go find a 100-line native Clojure library instead, and by now, there's 100-line native Clojure libraries for almost everything I need. For another example, the numeric tower is part of the core of Common Lisp, so it's usable from anywhere. BigInteger is a library in Java, and Java still doesn't seem to have rational or complex types, so Clojure does the best it can, but anything beyond fixnum arithmetic is basically opt-in, and almost no libraries use it. Debugging is even worse, because while there are a million google hits for "java library X", and a thousand hits for "lisp library Y", there's often almost no hits for "java library X with clojure". I have to mentally translate the Java X solutions into Clojure, and figure out any JVM/Clojure interop issues myself from first principles. That said, Clojure overall works great in practice, and for the most part you can ignore the JVM and its issues. But any time I'm forced to become aware that the JVM exists, my life ends up being worse than the equivalent scenario in the turtles-all-the-way-down world of other Lisps.