5 ms·

Bad idea. Better: Why Language Developers Should Stop Making Languages on Top of the JVM. Imagine if Ruby or Python were only available on top of the JVM... T

by 23david 14y ago

Bad idea. Better: Why Language Developers Should Stop Making Languages on Top of the JVM. Imagine if Ruby or Python were only available on top of the JVM... There may be a need for versions of a language that live in the JVM, but don't make the entire ecosystem dependent on it.

cgag 14y ago
Would you rather have the JVM as your ecosystem or no ecosystem at all?
- 23david 14y ago
  If Scala can't survive without the JVM perhaps it's just not a good idea. If enough people care about Scala they'll make it work independently of the JVM. JVM-based Scala is perhaps a good way to bootstrap the language, but I don't see how it's a great long-term strategy.
  - Evbn 14y ago
    And if people cared enough about Rails they would make it work independently of Ruby, except that makes no sense.
    - 23david 14y ago
      Nice lol. If enough people cared about Microsoft Office, they'd make it run without windows. Tons of similar and true examples. What about: If enough people cared about java they'd make it run without the jvm.
theboywho 14y ago
Ruby, Python, or Scala, they are all dependent on a VM. It just happens that for Scala (for now) the Scala VM _is_ the JVM (some folks even see this as a plus for Scala). It's more about Scala's features, syntax, design, etc that make the language worth checking out.
eranation 14y ago
Scala is a great way for enterprise developers to evolve a little toward functional programming. the JVM is still here to stay, and many Ruby web apps move to JRuby when they need to scale, and this is a fact. If we want to close the gap between enterprise and startups, Scala is a great way to go. and I'm sure it will have non JVM versions in the future, if not already. My language of choice at the moment, I like Ruby and Python, but I like a static typed language, I got used to it.
bunderbunder 14y ago
A big advantage to targeting one of the two big managed environments is that they come with batteries included. Unlike the Ruby and Python teams, Scala's developers didn't have to spend time on developing their own JIT compiler, or their own standard libraries, or their own memory manager, or any of that. Which is part of why it's so mature despite being so young. Open-source languages that don't target a managed environment have historically needed a lot longer to marinate than Scala did.
- 23david 14y ago
  So basically you're saying that they didn't want to do the hard work and used the JVM as a shortcut. Sounds like good engineering practice to me. When things get hard, just find a lazy shortcut. Marination is generally a good thing. Things come out tastier. Same for new languages. The robust Python / Ruby / PHP ecosystems seem to be working just fine without the JVM.
  - bunderbunder 14y ago
    Sounds like good engineering practice to me. Me too. After all, Scala's engineers weren't looking to create a whole new platform; they were just looking to create a new language. And a good engineer won't waste enormous amounts of time working on out-of-scope tangents unless there's a good reason to do so. NIH doesn't count as a good reason.
    - 23david 14y ago
      I agree. But as Scala gets more and more popular, they're going to become a whole ecosystem and platform unto themselves. But because they're on the JVM, all the new tools etc are going to be customized to handle unique JVM-only issues. It's a classic platform lock-in situation. And Oracle is driving the wheel here. Not sure how that's going to work out much better than all the great tools that were built on top of Microsoft's MFC framework. People didn't realize that it was a bad idea until it was too late to change. Sometimes in CS it really makes sense to build things slower and more carefully to avoid issues that may only come up years down the road.
chimeracoder 14y ago
In general, this is true, but the proper way to view Scala is as a 'fixed' version of Java. Scala isn't really competing for the same mindshare as Ruby/Python/etc., and for good reason. Scala is basically what Java should have been (or at least, that's the goal). Scala is not truly functional - like Java, it is object-oriented. It just so happens that, once you step outside the Java bastardization of that term and think about a more 'pure' OO, the result is fairly functional-looking. OO and FP aren't really competing paradigms; rather, OO is a more complex paradigm that can be constructed from a functional system. (The inverse is technically true too, but much uglier in practice). (To give an example of what I mean, Scala supports first-class objects, and functions/methods are included in that statement. Scala does not support first-class, module-level functions (outside an object). That's not functional programming; it's object-oriented! But if you design your OO system well, you get something similar. Java does this badly, because methods aren't first-class objects - and unlike C, you can't really use pointers/references to fake the same behavior, so you get the worst of both worlds). Of course, Scala has to deal with limitations of the JVM - that's their compromise to gain binary inter-compatibility - but the designs of the two languages are a night-and-day comparison.
- yummyfajitas 14y ago
  Scala does not support first-class, module-level functions (outside an object). Sure it does. object f { def apply(x: String) = s + " - foo" } Elsewhere: val t = f("bar")
  - chimeracoder 14y ago
    I don't understand what you mean. That's a function definition within an object; it's not top-level. EDIT: Okay, I see the confusion. That seems like a 'top-level' function in the sense that it's not acting on any parameter that's not explicitly passed to it, but it is still bound to the singleton object 'f'. That would be analogous to the following Python code: class F(object): def __init__(self): pass def x(self, s): return s + 'hi' >> Foo().x('hey') 'heyhi' Just because you ignore the implicit parameter doesn't mean it doesn't exist. Scala handles the implicit parameter differently, but the function still very much needs to exist inside the namespace of another object.
cfontes 14y ago
In fact it's not... Java JVM is a great piece of software it's extremely reliable and fast, the language is what sucks a bit ( I am a Java Dev btw ),If I remember right Ruby IN THE PAST had some problems with concurrency, and that is were JRuby came from (correct me, if I am wrong... No flame wars please.), so reinventing the well takes time and sometimes goes wrong for a while. Some wikipedia: "JRuby supports interpreted mode, AOT mode, and JIT mode (the last two modes are available since version 1.1[19]). JRuby evolved from being several times slower than Ruby Reference implementation[32], to being several times faster.[33] [34]." I learned a bit of Scala and I think it's a awesome lang, if you have time to learn it properly otherwise it might to pull your blanket, because it's a little trick at some things. I would definetly like to work with it, in fact I plan use it in my next side project together with Backbone.js
pswenson 14y ago
You didn't explain what's wrong with the JVM. Please do. The JVM is very fast and ubiquitous. Targeting the JVM allows the language developers to focus on the language rather than re-inventing a runtime (which is a monster project)
Evbn 14y ago
Scala runs on CLR too.

by 23david 14y ago

cgag 14y ago

Would you rather have the JVM as your ecosystem or no ecosystem at all?

23david 14y ago
If Scala can't survive without the JVM perhaps it's just not a good idea. If enough people care about Scala they'll make it work independently of the JVM. JVM-based Scala is perhaps a good way to bootstrap the language, but I don't see how it's a great long-term strategy.
- Evbn 14y ago
  And if people cared enough about Rails they would make it work independently of Ruby, except that makes no sense.
  - 23david 14y ago
    Nice lol. If enough people cared about Microsoft Office, they'd make it run without windows. Tons of similar and true examples. What about: If enough people cared about java they'd make it run without the jvm.

theboywho 14y ago

Ruby, Python, or Scala, they are all dependent on a VM. It just happens that for Scala (for now) the Scala VM _is_ the JVM (some folks even see this as a plus for Scala). It's more about Scala's features, syntax, design, etc that make the language worth checking out.

eranation 14y ago

Scala is a great way for enterprise developers to evolve a little toward functional programming. the JVM is still here to stay, and many Ruby web apps move to JRuby when they need to scale, and this is a fact. If we want to close the gap between enterprise and startups, Scala is a great way to go. and I'm sure it will have non JVM versions in the future, if not already. My language of choice at the moment, I like Ruby and Python, but I like a static typed language, I got used to it.

bunderbunder 14y ago

A big advantage to targeting one of the two big managed environments is that they come with batteries included. Unlike the Ruby and Python teams, Scala's developers didn't have to spend time on developing their own JIT compiler, or their own standard libraries, or their own memory manager, or any of that. Which is part of why it's so mature despite being so young. Open-source languages that don't target a managed environment have historically needed a lot longer to marinate than Scala did.

23david 14y ago
So basically you're saying that they didn't want to do the hard work and used the JVM as a shortcut. Sounds like good engineering practice to me. When things get hard, just find a lazy shortcut. Marination is generally a good thing. Things come out tastier. Same for new languages. The robust Python / Ruby / PHP ecosystems seem to be working just fine without the JVM.
- bunderbunder 14y ago
  Sounds like good engineering practice to me. Me too. After all, Scala's engineers weren't looking to create a whole new platform; they were just looking to create a new language. And a good engineer won't waste enormous amounts of time working on out-of-scope tangents unless there's a good reason to do so. NIH doesn't count as a good reason.
  - 23david 14y ago
    I agree. But as Scala gets more and more popular, they're going to become a whole ecosystem and platform unto themselves. But because they're on the JVM, all the new tools etc are going to be customized to handle unique JVM-only issues. It's a classic platform lock-in situation. And Oracle is driving the wheel here. Not sure how that's going to work out much better than all the great tools that were built on top of Microsoft's MFC framework. People didn't realize that it was a bad idea until it was too late to change. Sometimes in CS it really makes sense to build things slower and more carefully to avoid issues that may only come up years down the road.

chimeracoder 14y ago

In general, this is true, but the proper way to view Scala is as a 'fixed' version of Java. Scala isn't really competing for the same mindshare as Ruby/Python/etc., and for good reason. Scala is basically what Java should have been (or at least, that's the goal). Scala is not truly functional - like Java, it is object-oriented. It just so happens that, once you step outside the Java bastardization of that term and think about a more 'pure' OO, the result is fairly functional-looking. OO and FP aren't really competing paradigms; rather, OO is a more complex paradigm that can be constructed from a functional system. (The inverse is technically true too, but much uglier in practice). (To give an example of what I mean, Scala supports first-class objects, and functions/methods are included in that statement. Scala does not support first-class, module-level functions (outside an object). That's not functional programming; it's object-oriented! But if you design your OO system well, you get something similar. Java does this badly, because methods aren't first-class objects - and unlike C, you can't really use pointers/references to fake the same behavior, so you get the worst of both worlds). Of course, Scala has to deal with limitations of the JVM - that's their compromise to gain binary inter-compatibility - but the designs of the two languages are a night-and-day comparison.

yummyfajitas 14y ago
Scala does not support first-class, module-level functions (outside an object). Sure it does. object f { def apply(x: String) = s + " - foo" } Elsewhere: val t = f("bar")
- chimeracoder 14y ago
  I don't understand what you mean. That's a function definition within an object; it's not top-level. EDIT: Okay, I see the confusion. That seems like a 'top-level' function in the sense that it's not acting on any parameter that's not explicitly passed to it, but it is still bound to the singleton object 'f'. That would be analogous to the following Python code: class F(object): def __init__(self): pass def x(self, s): return s + 'hi' >> Foo().x('hey') 'heyhi' Just because you ignore the implicit parameter doesn't mean it doesn't exist. Scala handles the implicit parameter differently, but the function still very much needs to exist inside the namespace of another object.

cfontes 14y ago

In fact it's not... Java JVM is a great piece of software it's extremely reliable and fast, the language is what sucks a bit ( I am a Java Dev btw ),If I remember right Ruby IN THE PAST had some problems with concurrency, and that is were JRuby came from (correct me, if I am wrong... No flame wars please.), so reinventing the well takes time and sometimes goes wrong for a while. Some wikipedia: "JRuby supports interpreted mode, AOT mode, and JIT mode (the last two modes are available since version 1.1[19]). JRuby evolved from being several times slower than Ruby Reference implementation[32], to being several times faster.[33] [34]." I learned a bit of Scala and I think it's a awesome lang, if you have time to learn it properly otherwise it might to pull your blanket, because it's a little trick at some things. I would definetly like to work with it, in fact I plan use it in my next side project together with Backbone.js

pswenson 14y ago

You didn't explain what's wrong with the JVM. Please do. The JVM is very fast and ubiquitous. Targeting the JVM allows the language developers to focus on the language rather than re-inventing a runtime (which is a monster project)

Evbn 14y ago

Scala runs on CLR too.