5 ms·

Actually past releases do stop being maintained, updated and realistically can no longer be used for production, or even development due to bugs. Java is backw

Actually past releases do stop being maintained, updated and realistically can no longer be used for production, or even development due to bugs. Java is backwards compatible in the syntax, and future compilers have, so far, been able to compile old code as well. Will that be the thing for Scala?

adriaanm 12y ago
There's Scala 2.9 (and older) code out there in production. Maintenance for older versions can be had.
- kasey_junk 12y ago
  Scala 2.9 is 3 years old. That is a trivially short amount of time.
  - frowaway001 12y ago
    Seems to be on par with the practice of other vendors: Java SE releases are updated for the public with bug fixes, security fixes, and minor updates for a period of at least 3 years before the release reaches end-of-public- updates (EoPU). http://www.oracle.com/technetwork/java/eol-135779.html http://www.oracle.com/technetwork/java/eol-135779.html
    - kasey_junk 12y ago
      You can't possibly be comparing the binary and source compatibility of Java with Scala can you? I'm not an expert, but I haven't experienced a binary Java incompatibility in the wild and I've been using Java since before 1.0. As far as source compatibility you can count on 1 hand the incompatibilities between Java 1.4 released in 2002 with the current release and Java is not a paradigm for long term support! Instead of trying to shoot down everyone that points out an obvious disadvantage of Scala, and the backwards compatibility issue is an obvious one, a better approach would be to highlight what that trade off provides. Namely, Scala is free from the problems brought on by Java's strict backwards compatibility requirements and can continue to dramatically improve from version to version.
      - frowaway001 12y ago
        > Instead of trying to shoot down everyone that points out an obvious disadvantage of Scala, and the backwards compatibility issue is an obvious one, a better approach would be to highlight what that trade off provides. I'd love to do that, but when people are only interested in repeating stuff they read somewhere on the internet, but not discussing interesting things like how union types will change the way people will write code, how collections could be improved, or how the arity-limitation of tuples could be dropped–because that would actually involve thinking and doing some research–it's a hard thing to do. Especially when it's likely that I'm going to be accused of "moving the goal posts" when doing that. It's kind of sad that there is pretty much no insightful technical discussion happening on HN, but at least I can have some fun with "somebody is wrong on the internet" when people make wrong claims.
        kasey_junk 12y ago
        "I'd love to do that, but when people are only interested in repeating stuff they read somewhere on the internet..." "It's kind of sad that there is pretty much no insightful technical discussion happening on HN" Just as an FYI, in this 1 thread you've dismissively commented on some of the people responsible for the largest user bases of Scala and some of the oldest users of it. Maybe there would be more insightful technical discussions about Scala on HN if some of us who have actually written Scala in the wild didn't have to put up with derision every time we mention fairly obvious problems that we've encountered and instead could say things like "man useful automated refactorings would be really useful and who cares about tuple arity above 23 f'n parameters" Another hard thing to do is to deliver relevant business functionality. If your language/community doesn't make that easier, the faster it can be discarded the better.
        frowaway001 12y ago
        > and instead could say things [...] By all means say them, I think that would add something valuable to the debate. I'm just bored by people who keep complaining that Scala is not Java (which won't change) or make ridiculous comparisons with C++ (because constructive criticism seems to be too much work these days). I think most people heard that stuff 5 years ago, and it's just a waste of time. From my point of view, 80% of the comments are firmly focused on events in the past, not what can be learned from them for the future or what they would like to see in the next version. ---- So, given the announcement, which parts do you like, which parts do you consider unimportant and which parts are missing in your opinion? Why do you think removing the arity limit is not interesting? What's your approach when interacting with databases, were tables with tons of columns seem to occur in practice? What automatic refactorings would you like to see? Which impression do you have regarding ScalaIDE vs. the IntelliJ plugin? If you had a few wishes about improving Scala in the future, what would they be and how would you implement them?

adriaanm 12y ago

There's Scala 2.9 (and older) code out there in production. Maintenance for older versions can be had.

kasey_junk 12y ago
Scala 2.9 is 3 years old. That is a trivially short amount of time.
- frowaway001 12y ago
  Seems to be on par with the practice of other vendors: Java SE releases are updated for the public with bug fixes, security fixes, and minor updates for a period of at least 3 years before the release reaches end-of-public- updates (EoPU). http://www.oracle.com/technetwork/java/eol-135779.html http://www.oracle.com/technetwork/java/eol-135779.html
  - kasey_junk 12y ago
    You can't possibly be comparing the binary and source compatibility of Java with Scala can you? I'm not an expert, but I haven't experienced a binary Java incompatibility in the wild and I've been using Java since before 1.0. As far as source compatibility you can count on 1 hand the incompatibilities between Java 1.4 released in 2002 with the current release and Java is not a paradigm for long term support! Instead of trying to shoot down everyone that points out an obvious disadvantage of Scala, and the backwards compatibility issue is an obvious one, a better approach would be to highlight what that trade off provides. Namely, Scala is free from the problems brought on by Java's strict backwards compatibility requirements and can continue to dramatically improve from version to version.
    - frowaway001 12y ago
      > Instead of trying to shoot down everyone that points out an obvious disadvantage of Scala, and the backwards compatibility issue is an obvious one, a better approach would be to highlight what that trade off provides. I'd love to do that, but when people are only interested in repeating stuff they read somewhere on the internet, but not discussing interesting things like how union types will change the way people will write code, how collections could be improved, or how the arity-limitation of tuples could be dropped–because that would actually involve thinking and doing some research–it's a hard thing to do. Especially when it's likely that I'm going to be accused of "moving the goal posts" when doing that. It's kind of sad that there is pretty much no insightful technical discussion happening on HN, but at least I can have some fun with "somebody is wrong on the internet" when people make wrong claims.
      - kasey_junk 12y ago
        "I'd love to do that, but when people are only interested in repeating stuff they read somewhere on the internet..." "It's kind of sad that there is pretty much no insightful technical discussion happening on HN" Just as an FYI, in this 1 thread you've dismissively commented on some of the people responsible for the largest user bases of Scala and some of the oldest users of it. Maybe there would be more insightful technical discussions about Scala on HN if some of us who have actually written Scala in the wild didn't have to put up with derision every time we mention fairly obvious problems that we've encountered and instead could say things like "man useful automated refactorings would be really useful and who cares about tuple arity above 23 f'n parameters" Another hard thing to do is to deliver relevant business functionality. If your language/community doesn't make that easier, the faster it can be discarded the better.
        frowaway001 12y ago
        > and instead could say things [...] By all means say them, I think that would add something valuable to the debate. I'm just bored by people who keep complaining that Scala is not Java (which won't change) or make ridiculous comparisons with C++ (because constructive criticism seems to be too much work these days). I think most people heard that stuff 5 years ago, and it's just a waste of time. From my point of view, 80% of the comments are firmly focused on events in the past, not what can be learned from them for the future or what they would like to see in the next version. ---- So, given the announcement, which parts do you like, which parts do you consider unimportant and which parts are missing in your opinion? Why do you think removing the arity limit is not interesting? What's your approach when interacting with databases, were tables with tons of columns seem to occur in practice? What automatic refactorings would you like to see? Which impression do you have regarding ScalaIDE vs. the IntelliJ plugin? If you had a few wishes about improving Scala in the future, what would they be and how would you implement them?