7 ms·

You do realize that the compatibility issues are binary compatibility, not source compatibility right? It does seem to be the case that many Java project groups

You do realize that the compatibility issues are binary compatibility, not source compatibility right? It does seem to be the case that many Java project groups are not setup to build their dependencies from source, but for such a large code-base I think building dependencies from source and hosting your own binary repository is probably not a bad idea.

pron 12y ago
It's (almost) just as bad when you try to manage lots of dependencies. > but for such a large code-base I think building dependencies from source ... is probably not a bad idea. That's a bad idea. You want to manage as little code as possible, especially given the already large codebase. It's certainly doable, but in the end you realize the benefit is just not worth the effort. Of course, that was just a symptom of a far larger problem: It always seemed that when faced with the dilemma of favoring some PL research goal vs. real working-man's use, Scala always chose the former; it was like its real (though not stated) target audience were PL PhDs. It seems the winds have shifted recently, but probably too late, and Scala is already weighed down by too many "PhD" features that need to be removed in a way that would severely break source compatibility. Say what you want about Java, it's really great for big projects you must depend on and need to maintain for many years.
- frowaway001 12y ago
  Oh, what a surprise, pron is doing his FUD thing again.
  - llemiengre 12y ago
    As much as I would like to like technologies like quasar & pulsar, having a guy like pron work on it is enough to scare me away. Bashing the competition with FUD is never acceptable for me.
  - pron 12y ago
    I realize you're trolling, but let me try to explain this (hopefully for the last time): I can certainly understand why people don't like -- or don't choose to use -- the languages I choose to use (Clojure, Java, C). Hell, I can give you some very serious criticism against them myself (Java can become tedious to write, especially if you're working on relatively boring problems, and this might lead to demoralization, which is a very serious issue; in the past couple of years Clojure is also turning its attention to cleverness rather than getting things done, it's also not obvious how to construct and maintain a large-scale project in Clojure, and its syntax is a real turnoff to many developers; C's simplicity often comes at the expense of basic abstractions, like polymorphism, that actually assist in maintaining large codebases and dividing up work among developers, its concurrency story is severely lacking, and its security is terrible). So if someone tells me those languages aren't for them -- for example, hiring young developers and keeping them enthusiastic by using a clever language is more important to them than long-term maintenance of the project -- I get that, I really do. I also understand that you think it would be a wise decision on the part of Bank of America to write their software in Scala, or Raytheon to choose Scala for their aircraft carrier's C3I system; maybe you believe that a more expressive type system will lead to fewer bugs in such large systems, or that fewer lines of code offset its cleverness. You might think that the extreme lengths taken to ensure you never have to cast a type during collection transformations isn't PL-research showmanship that comes at the expense of code readability and getting stuff done, but a wise bug-preventing measure. But you should realize that people criticize your favorite language(s) for valid reasons. Maybe they have different constraints from yours, and maybe they favor other tradeoffs. Especially given that Scala -- unlike Java, Swift or Go -- was never meant to be "a language for everyone" (and neither is Clojure), it should come as no surprise that not everyone likes it, and for good reasons. Why, those reasons were deliberate! What I find annoying is trying to disown those decisions, deny those tradeoffs, and pretend Scala was a language designed not by professors and PhD students but by industry veterans. Both are, of course, excellent candidates for language design (look at Erlang and Haskell), but each group would choose different tradeoffs, and the languages they produce reflect that. Personally, I think "PL research" languages pave the path to the future and influence "industry" languages, but are often the wrong choice for serious industry projects. Going back to Erlang and Haskell, they're an interesting example because both try to solve kind of the same issues, and they're both superb languages; still, if the CTO of an airport asked me which language to use for their next critical system, I wouldn't hesitate before recommending Erlang and warning -- quite strongly, in fact -- against choosing Haskell.
- rtpg 12y ago
  >It's certainly doable, but in the end you realize the benefit is just not worth the effort. The benefit of using a language that, at _worst_, is as productive as Java, and at best miles better? >faced with the dilemma of favoring some PL research goal vs. real working-man's use, Scala always chose the first Scala is pretty straightforward in terms of features, classifying it as "PL research" is a bit much. >Say what you want about Java, it's really great for big projects you must depend on and need to maintain for many years. My experience has been that larger projects end up accumulating so much boilerplate that it becomes extremely hard to manage (I fear that Scala's standard library is becoming like this too, but third-party libs seem to avoid this). I have trouble finding any non-deployment-related argument against Scala in the Scala vs. Java comparison.
  - pron 12y ago
    > The benefit of using a language that, at _worst_, is as productive as Java, and at best miles better? I completely disagree with this. If "productive" means fewer lines of code -- then yes. But for a large-scale project, productive usually means code that another developer can understand quickly, and by that metric I think Scala loses big-time. > I have trouble finding any non-deployment-related argument against Scala in the Scala vs. Java comparison. Then either you haven't had enough experience with Scala (not on your own, but in a large team[1]) or you haven't looked. I and many others can list plenty, but I've said much of that before, and you can find a lot of other people's experiences online. In the end, it all comes down to tradeoffs, and you can find many valid arguments for both preferences. [1]: It can be argued that almost no one had (and neither have I) because Scala hasn't been around long enough, but overseeing development of (non-Scala) software that needs to last for at least a decade, as well as the later evolution of similar projects, it quickly became clear (to me, at least) that Scala isn't a great fit for such projects (at least not for many developers). People had a harder time understanding Scala code that was written by another team member a week earlier than Java code written 7 years earlier. While you certainly can be too clever in Java if you put in enough effort, it's waaay to easy in Scala. You can immediately see how the programmer became too bored of the actual problem they had to solve and decided to amuse themselves by playing with the language. This is something I've seen happen in C++ projects too, but to a lesser extent. I can guess that part of the reason is that when almost everyone was using C++, the internet, and certainly blogs, weren't so widespread and influential, so the really clever tricks couldn't spread so quickly. Also, when C++'s harm became apparent, discipline was quickly enforces in many organizations, and it was much easier to enforce discipline over C++ developers back then, than over Scala developers today, because many of those are cowboys to begin with. Still, maintaining long-lived C projects is easier than maintaining C++ projects, so much so that many wish they had chosen C over C++ when they first began development.
spullara 12y ago
There have been plenty of source compatibility issues since 2.7. Just ask anyone that works at Twitter how long it takes to upgrade between Scala versions.
- frowaway001 12y ago
  Did you explicitly pick 2.7, because compatibility guarantees became much stronger with 2.8 and later? Sometimes I wonder how many accounts that pron guy actually has.
  - heavenlyhash 12y ago
    ... You really don't have to follow many links to find out that Sam Pullara is quite a real person, and that he has in fact worked at Twitter. Twitter does, as a matter of public record, have some investments in scala, and I daresay some employees at twitter might have valid practical comments on the outcomes. Accusing one person of FUD, and then accusing him of sockpuppeting in the same thread, while failing miserably at turing-test level human detection... really, I think this comment does more credibility damage to itself than to anyone it's trying to cast shade upon.
    - frowaway001 12y ago
      What's the reason we have to look at prehistoric versions of Scala? That's like criticizing Java for the lack of Generics by picking Java 1.4 as a reference. It looks like the recent version upgrades for finagle and twitter-util were pretty smooth, so what's the point of picking old data over new?
      - kasey_junk 12y ago
        Your reaction is precisely why some of us feel that Scala is not ready for projects that are targeting long term backwards compatibility and are large. A 5 year old release is not prehistoric when you are thinking of building a system for the long term that will be very big. In that style of system you often see corners of the code base that are not touched for much longer than 5 years. The Scala team has further caused optic issues here by using what appears to be a semantic version number but in no way shape or form following semantic versioning procedures around compatibility breaking changes. [edit] Further bringing Java 1.4 into this is really problematic as it is past the 10 year mark on age and will run just fine with nearly any Java project right now.

pron 12y ago

It's (almost) just as bad when you try to manage lots of dependencies. > but for such a large code-base I think building dependencies from source ... is probably not a bad idea. That's a bad idea. You want to manage as little code as possible, especially given the already large codebase. It's certainly doable, but in the end you realize the benefit is just not worth the effort. Of course, that was just a symptom of a far larger problem: It always seemed that when faced with the dilemma of favoring some PL research goal vs. real working-man's use, Scala always chose the former; it was like its real (though not stated) target audience were PL PhDs. It seems the winds have shifted recently, but probably too late, and Scala is already weighed down by too many "PhD" features that need to be removed in a way that would severely break source compatibility. Say what you want about Java, it's really great for big projects you must depend on and need to maintain for many years.

frowaway001 12y ago
Oh, what a surprise, pron is doing his FUD thing again.
- llemiengre 12y ago
  As much as I would like to like technologies like quasar & pulsar, having a guy like pron work on it is enough to scare me away. Bashing the competition with FUD is never acceptable for me.
- pron 12y ago
  I realize you're trolling, but let me try to explain this (hopefully for the last time): I can certainly understand why people don't like -- or don't choose to use -- the languages I choose to use (Clojure, Java, C). Hell, I can give you some very serious criticism against them myself (Java can become tedious to write, especially if you're working on relatively boring problems, and this might lead to demoralization, which is a very serious issue; in the past couple of years Clojure is also turning its attention to cleverness rather than getting things done, it's also not obvious how to construct and maintain a large-scale project in Clojure, and its syntax is a real turnoff to many developers; C's simplicity often comes at the expense of basic abstractions, like polymorphism, that actually assist in maintaining large codebases and dividing up work among developers, its concurrency story is severely lacking, and its security is terrible). So if someone tells me those languages aren't for them -- for example, hiring young developers and keeping them enthusiastic by using a clever language is more important to them than long-term maintenance of the project -- I get that, I really do. I also understand that you think it would be a wise decision on the part of Bank of America to write their software in Scala, or Raytheon to choose Scala for their aircraft carrier's C3I system; maybe you believe that a more expressive type system will lead to fewer bugs in such large systems, or that fewer lines of code offset its cleverness. You might think that the extreme lengths taken to ensure you never have to cast a type during collection transformations isn't PL-research showmanship that comes at the expense of code readability and getting stuff done, but a wise bug-preventing measure. But you should realize that people criticize your favorite language(s) for valid reasons. Maybe they have different constraints from yours, and maybe they favor other tradeoffs. Especially given that Scala -- unlike Java, Swift or Go -- was never meant to be "a language for everyone" (and neither is Clojure), it should come as no surprise that not everyone likes it, and for good reasons. Why, those reasons were deliberate! What I find annoying is trying to disown those decisions, deny those tradeoffs, and pretend Scala was a language designed not by professors and PhD students but by industry veterans. Both are, of course, excellent candidates for language design (look at Erlang and Haskell), but each group would choose different tradeoffs, and the languages they produce reflect that. Personally, I think "PL research" languages pave the path to the future and influence "industry" languages, but are often the wrong choice for serious industry projects. Going back to Erlang and Haskell, they're an interesting example because both try to solve kind of the same issues, and they're both superb languages; still, if the CTO of an airport asked me which language to use for their next critical system, I wouldn't hesitate before recommending Erlang and warning -- quite strongly, in fact -- against choosing Haskell.
rtpg 12y ago
>It's certainly doable, but in the end you realize the benefit is just not worth the effort. The benefit of using a language that, at _worst_, is as productive as Java, and at best miles better? >faced with the dilemma of favoring some PL research goal vs. real working-man's use, Scala always chose the first Scala is pretty straightforward in terms of features, classifying it as "PL research" is a bit much. >Say what you want about Java, it's really great for big projects you must depend on and need to maintain for many years. My experience has been that larger projects end up accumulating so much boilerplate that it becomes extremely hard to manage (I fear that Scala's standard library is becoming like this too, but third-party libs seem to avoid this). I have trouble finding any non-deployment-related argument against Scala in the Scala vs. Java comparison.
- pron 12y ago
  > The benefit of using a language that, at _worst_, is as productive as Java, and at best miles better? I completely disagree with this. If "productive" means fewer lines of code -- then yes. But for a large-scale project, productive usually means code that another developer can understand quickly, and by that metric I think Scala loses big-time. > I have trouble finding any non-deployment-related argument against Scala in the Scala vs. Java comparison. Then either you haven't had enough experience with Scala (not on your own, but in a large team[1]) or you haven't looked. I and many others can list plenty, but I've said much of that before, and you can find a lot of other people's experiences online. In the end, it all comes down to tradeoffs, and you can find many valid arguments for both preferences. [1]: It can be argued that almost no one had (and neither have I) because Scala hasn't been around long enough, but overseeing development of (non-Scala) software that needs to last for at least a decade, as well as the later evolution of similar projects, it quickly became clear (to me, at least) that Scala isn't a great fit for such projects (at least not for many developers). People had a harder time understanding Scala code that was written by another team member a week earlier than Java code written 7 years earlier. While you certainly can be too clever in Java if you put in enough effort, it's waaay to easy in Scala. You can immediately see how the programmer became too bored of the actual problem they had to solve and decided to amuse themselves by playing with the language. This is something I've seen happen in C++ projects too, but to a lesser extent. I can guess that part of the reason is that when almost everyone was using C++, the internet, and certainly blogs, weren't so widespread and influential, so the really clever tricks couldn't spread so quickly. Also, when C++'s harm became apparent, discipline was quickly enforces in many organizations, and it was much easier to enforce discipline over C++ developers back then, than over Scala developers today, because many of those are cowboys to begin with. Still, maintaining long-lived C projects is easier than maintaining C++ projects, so much so that many wish they had chosen C over C++ when they first began development.

spullara 12y ago

There have been plenty of source compatibility issues since 2.7. Just ask anyone that works at Twitter how long it takes to upgrade between Scala versions.

frowaway001 12y ago
Did you explicitly pick 2.7, because compatibility guarantees became much stronger with 2.8 and later? Sometimes I wonder how many accounts that pron guy actually has.
- heavenlyhash 12y ago
  ... You really don't have to follow many links to find out that Sam Pullara is quite a real person, and that he has in fact worked at Twitter. Twitter does, as a matter of public record, have some investments in scala, and I daresay some employees at twitter might have valid practical comments on the outcomes. Accusing one person of FUD, and then accusing him of sockpuppeting in the same thread, while failing miserably at turing-test level human detection... really, I think this comment does more credibility damage to itself than to anyone it's trying to cast shade upon.
  - frowaway001 12y ago
    What's the reason we have to look at prehistoric versions of Scala? That's like criticizing Java for the lack of Generics by picking Java 1.4 as a reference. It looks like the recent version upgrades for finagle and twitter-util were pretty smooth, so what's the point of picking old data over new?
    - kasey_junk 12y ago
      Your reaction is precisely why some of us feel that Scala is not ready for projects that are targeting long term backwards compatibility and are large. A 5 year old release is not prehistoric when you are thinking of building a system for the long term that will be very big. In that style of system you often see corners of the code base that are not touched for much longer than 5 years. The Scala team has further caused optic issues here by using what appears to be a semantic version number but in no way shape or form following semantic versioning procedures around compatibility breaking changes. [edit] Further bringing Java 1.4 into this is really problematic as it is past the 10 year mark on age and will run just fine with nearly any Java project right now.