5 ms·

i stopped reading when i saw "JVM". i really dont get it why this is so popular... maybe it makes your code faster yes but it comes with all the cluter that is

by lampe 14y ago

i stopped reading when i saw "JVM". i really dont get it why this is so popular... maybe it makes your code faster yes but it comes with all the cluter that is the JVM. The JVM is a big black box and I think its veryhard to see whats happening inside. have someone tried to write a patch for the JVM? no? then try!

skrebbel 14y ago
Integration, ecosystem, exit strategy. Integration so that you can easily integrate new Smalltalk code (in this case) with existing JVM code that your organisation/product might have. Ecosystem because you don't need to kickstart a massive community of developers, open source libraries, a standard library, and so on, to have a useful language. Basically, by making a language that targets an existing platform (such as the JVM, CLR or JavaScript), you're "batteries included" from the very start. Better yet, the batteries will be familiar to shares of developers. This is major. Ever wondered why Lisp was only used by a couple of men with beards (and pg) until Clojure? I can promise you, it wasn't the square brackets. Exit strategy because you want to be able to get out as easily as you got in. If you build non-hobby software with Redline Smalltalk, and for whatever reason the whole thing blows up in your face (e.g. big performance or security problems, project ends up unmaintained with large nuisances, and so on), you can migrate code to another JVM language bit by bit.
- supar 14y ago
  I could say exactly the same for any source-to-C compiler, and/or any system allowing decent FFI with C. Unless there is some different reason than the JVM itself, C has an even larger code base.
  - skrebbel 14y ago
    In a way, C can be considered an "existing platform" in much the same sense. I didn't include it in my list of examples because I really don't want to have to fight build tooling and cross-platform dependency hell in 2012 if I don't absolutely have to. With e.g. the JVM, you can get a jar from somewhere (or maven it in), and -poof- it just works, everywhere. This is a major advantage to the whole "ecosystem" point.
- pron 14y ago
  True, and I would also add the best performance of any managed runtime and the best profiling of any runtime. Unless your language's main features coincide with the very specific pain points poorly addressed by the JVM (like struct arrays or mobile-phone deployment), I'll say that the JVM is the default target choice. It is any other choice that will need to be justified.
wr1472 14y ago
"The JVM is a big black box and I think its veryhard to see whats happening inside." Good software engineering is very much about standing on the shoulders of giants. "have someone tried to write a patch for the JVM? no? then try!" How often do people need to do this in everyday development on the JVM?
- TallGuyShort 14y ago
  Any language that someone is arguing should be "the next big language" should take things other than everyday development on the JVM. Nevertheless, wanting to be able to patch the JVM has been a part of my "everday development" several times.
  - jbooth 14y ago
    "everyday development"? Really? Could you explain which behavior needed patching? Garbage collection, I'm guessing? I'm not saying the JVM is perfect but I'm inclined to think that if the JVM is causing you problems, you already had them in your architecture.
    - deleted 14y ago
      [deleted]
jerven 14y ago
Have you tried writing a patch for one of the large C compilers? and getting it into mainline? not trivial either. For the JVM there are choices. IBM, Azul, Oracle, OpenJDK and many other more academic ones. With different tradeoffs and costs. I have switched massive code bases from one to the other with minimal effort. Switching C compiler is more invasive than switching JVM providers. And many other languages only have a single sanctioned runtime. Sure the JVM eco system is far from perfect. But it is dependable!
d4nt 14y ago
I understand why people choose the JVM, I'm sure it gets people up and running very quickly, and maybe if you're an enterprise java programmer then getting set up on the latest cool JVM based language is quite easy. But speaking as a Python/JS/.Net guy who once spent a few evenings trying to build something in Scala, the JVM just seems so painful to use. I lost hours trying to set up Maven to download one library and build my project. All the documentation pages seemed to point to other documentation pages. I ended up trying to download about 30 jars manually, but the versions seemed to clash. I am convinced that the best thing a programming language can to do improve adoption is not to create a JVM version, but to create a package management system like pip/npm/NuGet.
- justinhj 14y ago
  The first couple of days with a language can be painful. People have trouble getting python libraries to work too. Maven is really quite well thought out and solid.
  - stcredzero 14y ago
    > The first couple of days with a language can be painful. It doesn't have to be: http://xkcd.com/353/ http://xkcd.com/353/
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]

by lampe 14y ago

skrebbel 14y ago

Integration, ecosystem, exit strategy. Integration so that you can easily integrate new Smalltalk code (in this case) with existing JVM code that your organisation/product might have. Ecosystem because you don't need to kickstart a massive community of developers, open source libraries, a standard library, and so on, to have a useful language. Basically, by making a language that targets an existing platform (such as the JVM, CLR or JavaScript), you're "batteries included" from the very start. Better yet, the batteries will be familiar to shares of developers. This is major. Ever wondered why Lisp was only used by a couple of men with beards (and pg) until Clojure? I can promise you, it wasn't the square brackets. Exit strategy because you want to be able to get out as easily as you got in. If you build non-hobby software with Redline Smalltalk, and for whatever reason the whole thing blows up in your face (e.g. big performance or security problems, project ends up unmaintained with large nuisances, and so on), you can migrate code to another JVM language bit by bit.

supar 14y ago
I could say exactly the same for any source-to-C compiler, and/or any system allowing decent FFI with C. Unless there is some different reason than the JVM itself, C has an even larger code base.
- skrebbel 14y ago
  In a way, C can be considered an "existing platform" in much the same sense. I didn't include it in my list of examples because I really don't want to have to fight build tooling and cross-platform dependency hell in 2012 if I don't absolutely have to. With e.g. the JVM, you can get a jar from somewhere (or maven it in), and -poof- it just works, everywhere. This is a major advantage to the whole "ecosystem" point.
pron 14y ago
True, and I would also add the best performance of any managed runtime and the best profiling of any runtime. Unless your language's main features coincide with the very specific pain points poorly addressed by the JVM (like struct arrays or mobile-phone deployment), I'll say that the JVM is the default target choice. It is any other choice that will need to be justified.

wr1472 14y ago

"The JVM is a big black box and I think its veryhard to see whats happening inside." Good software engineering is very much about standing on the shoulders of giants. "have someone tried to write a patch for the JVM? no? then try!" How often do people need to do this in everyday development on the JVM?

TallGuyShort 14y ago
Any language that someone is arguing should be "the next big language" should take things other than everyday development on the JVM. Nevertheless, wanting to be able to patch the JVM has been a part of my "everday development" several times.
- jbooth 14y ago
  "everyday development"? Really? Could you explain which behavior needed patching? Garbage collection, I'm guessing? I'm not saying the JVM is perfect but I'm inclined to think that if the JVM is causing you problems, you already had them in your architecture.
  - deleted 14y ago
    [deleted]

jerven 14y ago

Have you tried writing a patch for one of the large C compilers? and getting it into mainline? not trivial either. For the JVM there are choices. IBM, Azul, Oracle, OpenJDK and many other more academic ones. With different tradeoffs and costs. I have switched massive code bases from one to the other with minimal effort. Switching C compiler is more invasive than switching JVM providers. And many other languages only have a single sanctioned runtime. Sure the JVM eco system is far from perfect. But it is dependable!

d4nt 14y ago

I understand why people choose the JVM, I'm sure it gets people up and running very quickly, and maybe if you're an enterprise java programmer then getting set up on the latest cool JVM based language is quite easy. But speaking as a Python/JS/.Net guy who once spent a few evenings trying to build something in Scala, the JVM just seems so painful to use. I lost hours trying to set up Maven to download one library and build my project. All the documentation pages seemed to point to other documentation pages. I ended up trying to download about 30 jars manually, but the versions seemed to clash. I am convinced that the best thing a programming language can to do improve adoption is not to create a JVM version, but to create a package management system like pip/npm/NuGet.

justinhj 14y ago
The first couple of days with a language can be painful. People have trouble getting python libraries to work too. Maven is really quite well thought out and solid.
- stcredzero 14y ago
  > The first couple of days with a language can be painful. It doesn't have to be: http://xkcd.com/353/ http://xkcd.com/353/
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]