5 ms·

I don't understand this sentiment. How is installing JRE any diffierent than installing Ruby?

by unmole 8y ago

jxub 8y ago
It means installing a big runtime they aren't familiar with, and getting their feet wet with a huge ecosystem which spans from weird stacktraces to the standard libraries and beyond, and is associated (somehow wrongly) with boring code and old enterprise solutions.
- olieidel 8y ago
  The almost exact same could be said for Ruby and frankly, any other programming language which has stacktraces and a standard library.
  - szemet 8y ago
    Clojure stack traces are usually long and somewhat leaky, they are hard to read without (and sometimes even with) preexisting knowledge about Java / JVM / Clojure implementation details. https://ioavisopretty.readthedocs.io/en/v0.1.34/exceptions.html https://ioavisopretty.readthedocs.io/en/v0.1.34/exceptions.h... https://lispcast.com/clojure-error-messages-accidental/ https://lispcast.com/clojure-error-messages-accidental/
    - dragandj 8y ago
      On the other hand, with some Java/JVM knowledge, they are very helpful. Whenever I come across supposedly nice error messages in most other languages, I'm convinced more and more that stacktraces are one of the right ways to do it...
    - nathell 8y ago
      Clojure error messages are on slate for improvement in 1.10, though: https://mobile.twitter.com/puredanger/status/1028103654241443840 https://mobile.twitter.com/puredanger/status/102810365424144...
    - pjmlp 8y ago
      Platform details are eventually going to leak, regardless of which one gets targeted.
  - pankajdoharey 8y ago
    Actually that is not true, Ruby stack traces are beautiful. Recently i saw a feature called "Did you Mean?" Have you ever seen such a stack trace in any other language? Clojures Stack traces are unreadable. My strategy with clojure debugging is usually commenting code and println thats how bad stack traces are in clojure but the thing is Clojure as a language is very thoughtful and thought provoking much more than any scheme i have seen. And certainly more enjoyable to code in than Ruby.
    - pankajdoharey 8y ago
      Folks at-least comment with a good reason before giving negative points for a comment. It helps clarify how the message was received a negative point without a comment is quite pointless and banal.
pankajdoharey 8y ago
I am not sure how do i explain this, but a lot of people think about JVM with verbose slow VM code that works in the enterprise. java binary doesnt even follow unix styled cli options. the worded cli options are single hyphenated. There are many oddities associated with JVM/Java which are purely superficial. But yet a lot of people think it is irritation to use JVM, plus the perceived notion of Enterprise bloatware.
- kjeetgill 8y ago
  I get it, I make broad aesthetic choices about my technology too. Especially to avoid picking up an ecosystem I'd otherwise get to avoid ... so I'll add my own sterotypes. Aren't all those crticisms double for Ruby? And Node? You're adding a runtime, a package manager, and packages to your system with all three but two of them are just raw source code ...
- klibertp 8y ago
  > a lot of people think about JVM with verbose slow VM code that works in the enterprise They are severely misinformed, then, and it would be a good deed to give them an opportunity to learn more about this. Which is: Java is fast. Its startup time is impressive, and the runtime performance is generally also good. RAM usage could be less impressive, but I read that it can be optimized for memory consumption, achieving pretty good results - I don't have any experience here, so I can't really say. Anyway, my problem with Java, is that it is not designed to be used on its own. To use it, you need a build system, and the language doesn't give you one; which is why there are many different systems, which you need to navigate somehow. Having to learn these build system (XML? custom Groovy implementation?) is what made me dislike Java. It's not that different in C++ or C#, but it adds to the feeling that you work with an ancient technology, not a modern one. That's however not the problem with Clojure - it at least has a single build system + package manager - Leiningen. To me, what disqualifies it, is the startup time of its REPL. Well, that's only because I have a luxury of not needing to do anything on the JVM - so I'm speaking from a position of a hobbyist polyglot programmer considering new languages to learn. I would probably reconsider if I had a job where JVM would be a must, but the specific language was not yet chosen (how probable that would be is another matter). Anyway, back on topic: I don't have Clojure on this machine, but last time I tried it, it took more than a second before the prompt appeared. That is slow even when considered on its own, but it borders ludicrous (speed) when compared with other Lisps, which seems to be the right frame of reference here. In that comparison, it's... Well, just to let you know how bad it is, Common Lisp and Chicken Scheme, two Lisps I do have on this machine, have startup (+ shutdown!) times like this: -▶ time sbcl --eval "(exit)" This is SBCL 1.4.6-1.fc28, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. sbcl --eval "(exit)" 0,00s user 0,00s system 94% cpu 0,006 total -▶ time csi -e "(exit)" csi -e "(exit)" 0,00s user 0,00s system 93% cpu 0,005 total Now, two things: 1) I get it that "you're supposed to have a deamon process in the background, so you don't need to start that often", but this, in itself, is basically announcing surrender. In Common Lisp you're supposed to do the same, but not by necessity! 2) Yes, I tried alternative runtimes/implementations. Indeed, they are better. However, until they get, provably, 99% the same semantics as the reference implementation, they won't be adopted by any significant amount of people, which has enough of the drawbacks to make me not seriously consider using them. Anecdotally, last time I looked, I've seen lots of lein plugins for setting up projects with ClojureScript on the frontend and some (pure) Clojure Web framework on the backend. There has to be a reason behind that. TLDR: Java is very fast, Clojure uses JVM in ways which are inherently slow on that VM, but refuses to honestly migrate to a more suitable platform, because of Java ecosystem, which is also a major selling point of the language. At least, that's my understanding of the situation - if I'm wrong, I'd be happy to get corrected.
agumonkey 8y ago
java is a behemoth~, ruby is human sensible
- pankajdoharey 8y ago
  Ruby is great but its VM is no match for JVM. Still a kid on the block recently started experimenting with JIT. Its a long way to go before YARV can come close to JVM Performance.
  - agumonkey 8y ago
    oh I knew, it's not about perf, it's about perspective. Kinda like python.. Last week I've read some physicist saying he stopped cpp after 15 years to write python. It was more human friendly to write python and few performant bits in C than dealing with cpp culture. I'm sure that's the same for Java.
    - divs1210 8y ago
      we are talking about the platform - the JVM - not the Java language. You can run Python, Ruby, JS, Clojure etc. on the JVM apart from Java.

I don't understand this sentiment. How is installing JRE any diffierent than installing Ruby?

by unmole 8y ago

I don't understand this sentiment. How is installing JRE any diffierent than installing Ruby?

jxub 8y ago

It means installing a big runtime they aren't familiar with, and getting their feet wet with a huge ecosystem which spans from weird stacktraces to the standard libraries and beyond, and is associated (somehow wrongly) with boring code and old enterprise solutions.

olieidel 8y ago
The almost exact same could be said for Ruby and frankly, any other programming language which has stacktraces and a standard library.
- szemet 8y ago
  Clojure stack traces are usually long and somewhat leaky, they are hard to read without (and sometimes even with) preexisting knowledge about Java / JVM / Clojure implementation details. https://ioavisopretty.readthedocs.io/en/v0.1.34/exceptions.html https://ioavisopretty.readthedocs.io/en/v0.1.34/exceptions.h... https://lispcast.com/clojure-error-messages-accidental/ https://lispcast.com/clojure-error-messages-accidental/
  - dragandj 8y ago
    On the other hand, with some Java/JVM knowledge, they are very helpful. Whenever I come across supposedly nice error messages in most other languages, I'm convinced more and more that stacktraces are one of the right ways to do it...
  - nathell 8y ago
    Clojure error messages are on slate for improvement in 1.10, though: https://mobile.twitter.com/puredanger/status/1028103654241443840 https://mobile.twitter.com/puredanger/status/102810365424144...
  - pjmlp 8y ago
    Platform details are eventually going to leak, regardless of which one gets targeted.
- pankajdoharey 8y ago
  Actually that is not true, Ruby stack traces are beautiful. Recently i saw a feature called "Did you Mean?" Have you ever seen such a stack trace in any other language? Clojures Stack traces are unreadable. My strategy with clojure debugging is usually commenting code and println thats how bad stack traces are in clojure but the thing is Clojure as a language is very thoughtful and thought provoking much more than any scheme i have seen. And certainly more enjoyable to code in than Ruby.
  - pankajdoharey 8y ago
    Folks at-least comment with a good reason before giving negative points for a comment. It helps clarify how the message was received a negative point without a comment is quite pointless and banal.

pankajdoharey 8y ago

I am not sure how do i explain this, but a lot of people think about JVM with verbose slow VM code that works in the enterprise. java binary doesnt even follow unix styled cli options. the worded cli options are single hyphenated. There are many oddities associated with JVM/Java which are purely superficial. But yet a lot of people think it is irritation to use JVM, plus the perceived notion of Enterprise bloatware.

kjeetgill 8y ago
I get it, I make broad aesthetic choices about my technology too. Especially to avoid picking up an ecosystem I'd otherwise get to avoid ... so I'll add my own sterotypes. Aren't all those crticisms double for Ruby? And Node? You're adding a runtime, a package manager, and packages to your system with all three but two of them are just raw source code ...
klibertp 8y ago
> a lot of people think about JVM with verbose slow VM code that works in the enterprise They are severely misinformed, then, and it would be a good deed to give them an opportunity to learn more about this. Which is: Java is fast. Its startup time is impressive, and the runtime performance is generally also good. RAM usage could be less impressive, but I read that it can be optimized for memory consumption, achieving pretty good results - I don't have any experience here, so I can't really say. Anyway, my problem with Java, is that it is not designed to be used on its own. To use it, you need a build system, and the language doesn't give you one; which is why there are many different systems, which you need to navigate somehow. Having to learn these build system (XML? custom Groovy implementation?) is what made me dislike Java. It's not that different in C++ or C#, but it adds to the feeling that you work with an ancient technology, not a modern one. That's however not the problem with Clojure - it at least has a single build system + package manager - Leiningen. To me, what disqualifies it, is the startup time of its REPL. Well, that's only because I have a luxury of not needing to do anything on the JVM - so I'm speaking from a position of a hobbyist polyglot programmer considering new languages to learn. I would probably reconsider if I had a job where JVM would be a must, but the specific language was not yet chosen (how probable that would be is another matter). Anyway, back on topic: I don't have Clojure on this machine, but last time I tried it, it took more than a second before the prompt appeared. That is slow even when considered on its own, but it borders ludicrous (speed) when compared with other Lisps, which seems to be the right frame of reference here. In that comparison, it's... Well, just to let you know how bad it is, Common Lisp and Chicken Scheme, two Lisps I do have on this machine, have startup (+ shutdown!) times like this: -▶ time sbcl --eval "(exit)" This is SBCL 1.4.6-1.fc28, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. sbcl --eval "(exit)" 0,00s user 0,00s system 94% cpu 0,006 total -▶ time csi -e "(exit)" csi -e "(exit)" 0,00s user 0,00s system 93% cpu 0,005 total Now, two things: 1) I get it that "you're supposed to have a deamon process in the background, so you don't need to start that often", but this, in itself, is basically announcing surrender. In Common Lisp you're supposed to do the same, but not by necessity! 2) Yes, I tried alternative runtimes/implementations. Indeed, they are better. However, until they get, provably, 99% the same semantics as the reference implementation, they won't be adopted by any significant amount of people, which has enough of the drawbacks to make me not seriously consider using them. Anecdotally, last time I looked, I've seen lots of lein plugins for setting up projects with ClojureScript on the frontend and some (pure) Clojure Web framework on the backend. There has to be a reason behind that. TLDR: Java is very fast, Clojure uses JVM in ways which are inherently slow on that VM, but refuses to honestly migrate to a more suitable platform, because of Java ecosystem, which is also a major selling point of the language. At least, that's my understanding of the situation - if I'm wrong, I'd be happy to get corrected.

agumonkey 8y ago

java is a behemoth~, ruby is human sensible

pankajdoharey 8y ago
Ruby is great but its VM is no match for JVM. Still a kid on the block recently started experimenting with JIT. Its a long way to go before YARV can come close to JVM Performance.
- agumonkey 8y ago
  oh I knew, it's not about perf, it's about perspective. Kinda like python.. Last week I've read some physicist saying he stopped cpp after 15 years to write python. It was more human friendly to write python and few performant bits in C than dealing with cpp culture. I'm sure that's the same for Java.
  - divs1210 8y ago
    we are talking about the platform - the JVM - not the Java language. You can run Python, Ruby, JS, Clojure etc. on the JVM apart from Java.