4 ms·

1. If you could manage to make a single point without using multiple strawmen and sweeping generalizations, people would take you more seriously.

1. If you could manage to make a single point without using multiple strawmen and sweeping generalizations, people would take you more seriously. 2. Just read your own text. You have made up your mind (perfectly fine), but you are desperately making up arbitrary claims to fit your own view (increasingly ridiculous). 3. Additionally, you are completely unable to refer to specific instances of what you think is wrong and only respond with abstract platitudes which could include everything or nothing. 4. Reading a bit about Scala on the Internet and repeating it doesn't make you an expert. That's the issue.

pron 12y ago
You can dismiss my claims (hey, I'm just expressing my opinion), but to make one point clear: I have over 20 years experience writing software professionally (yeah, I got my first paid programming gig at a relatively young age), and I've been following Scala since its initial release. A few years ago I tried switching my project's team from Java to Scala, and the results of the experiment were very negative. True, my hands-on Scala experience (which was rather comprehensive at the time) ended several years ago, but much has changed for the worse since then, though some has changed for the better in the past few years. I don't need to try and switch a ten people team to Scala with every major version in order to make valid claims. What killed us then was that Scala was posing as "a better Java" -- less boilerplate etc. -- while in fact it was "a more complex Haskell, minus all the constraints which make Haskell safe" (in addition there were serious compatibility issues and more). We found that Scala code was less readable, and getting people to understand other people's code was a lot harder than in Java. In short, the language was the exact opposite of what a large scale, dependable project required, so we ended the experiment. Since then, Scala has gotten a lot more complex with even more features. Also, your insistence that Scala isn't a research language is based on... I don't know what. Unlike, say, Clojure or Erlang, that tried to solve specific software engineering pain points (state management, fault tolerance), Scala started as a research language designed to test a PL hypothesis: how well can FP and OOP mesh, and will doing so be helpful. It also experimented with advanced type systems, and recently with statically typed language. None of the motivations behind these features was an industry problem. No one in the industry said, "you know what, type safe macros is what's going to make our automation control software easier to maintain". Their motivation came from conjectures compiler writers had about novel language features and how they might be used when writing a piece of code. You can deny this all you want, but those are facts. What is opinion is the analysis of the result: I claim that the result is a kitchen-sink language with too many features -- most of them marginally useful when building the next stock-market exchange -- and all of them contribute complexity whose cost far exceeds its benefit, resulting in a language whose net contribution to industry projects (not research projects) is negative. Feel free to disagree. If you think valid claims only pertain to the discussion of the for comprehension syntax, then you should try managing large projects and see that it's the philosophy of the language and combination of features that matters.
- frowaway001 12y ago
  This is not about disagreement. You keep making huge claims and sweeping generalizations based on a completely irrelevant version of Scala ("a few years ago" == "not a version which would give any useful information to judge Scala today"), without being able to support any of it with even a glimpse of detail. At the same time, you come up with requirements where there is just no chance to actual fulfill them, e. g. bashing the language for both being not production-ready before 2.8 (is that even a point worth discussing?) and for rapidly improving on exactly these issues (OMG!!! It is changing too fast!). I think you should really make your mind up on these things, because you can't have it both ways. I'm saying this because this incoherent reasoning is constantly happening in your comments, it's not some isolated case.
  - pron 12y ago
    > without being able to support any of it with even a glimpse of detail. I'm sorry, but you're just not getting it. I don't take issue with Scala's choice of square brackets over angled brackets. I take issue with the language philosophy and combined set of features. Here are the most detailed details: too many features, many of them overlapping (traits, structural types); too much complexity (type system, implicits); less readable; not enough constraints (e.g. immutability not enforced, casts allowed everywhere). That's as detailed as it gets. All in all, it came out benefits << cost. That's it. Either you don't want to understand or you think that when Boeing wants to write some big aircraft software thingy they say, "hmmm., the type inference is insufficient for our needs", or, "if only we had non-strict evaluation...". Because that's not how it works. In the industry languages are evaluated as a whole based on the project's criteria, with all their combined benefits weighed against their combined costs. This is what we've done. Scala came out lacking: too much overall cost for too little overall benefit. It was too complicated, too unconstraining, too unreadable, and too difficult to upgrade and build. What more do you want? > "not a version which would give any useful information to judge Scala today" No, I'm sorry, but you're just plain wrong! I gave up on Scala some years ago, but I can still tell its evolution has been in the opposite direction from what we wanted. Since then the language has become even bigger, more complex, more obtuse (collections) and even less constraining (macros). Even if the build and upgrade issues are better, the PL research philosophy is still there and its effects are only worse than they were some years ago.

pron 12y ago

You can dismiss my claims (hey, I'm just expressing my opinion), but to make one point clear: I have over 20 years experience writing software professionally (yeah, I got my first paid programming gig at a relatively young age), and I've been following Scala since its initial release. A few years ago I tried switching my project's team from Java to Scala, and the results of the experiment were very negative. True, my hands-on Scala experience (which was rather comprehensive at the time) ended several years ago, but much has changed for the worse since then, though some has changed for the better in the past few years. I don't need to try and switch a ten people team to Scala with every major version in order to make valid claims. What killed us then was that Scala was posing as "a better Java" -- less boilerplate etc. -- while in fact it was "a more complex Haskell, minus all the constraints which make Haskell safe" (in addition there were serious compatibility issues and more). We found that Scala code was less readable, and getting people to understand other people's code was a lot harder than in Java. In short, the language was the exact opposite of what a large scale, dependable project required, so we ended the experiment. Since then, Scala has gotten a lot more complex with even more features. Also, your insistence that Scala isn't a research language is based on... I don't know what. Unlike, say, Clojure or Erlang, that tried to solve specific software engineering pain points (state management, fault tolerance), Scala started as a research language designed to test a PL hypothesis: how well can FP and OOP mesh, and will doing so be helpful. It also experimented with advanced type systems, and recently with statically typed language. None of the motivations behind these features was an industry problem. No one in the industry said, "you know what, type safe macros is what's going to make our automation control software easier to maintain". Their motivation came from conjectures compiler writers had about novel language features and how they might be used when writing a piece of code. You can deny this all you want, but those are facts. What is opinion is the analysis of the result: I claim that the result is a kitchen-sink language with too many features -- most of them marginally useful when building the next stock-market exchange -- and all of them contribute complexity whose cost far exceeds its benefit, resulting in a language whose net contribution to industry projects (not research projects) is negative. Feel free to disagree. If you think valid claims only pertain to the discussion of the for comprehension syntax, then you should try managing large projects and see that it's the philosophy of the language and combination of features that matters.

frowaway001 12y ago
This is not about disagreement. You keep making huge claims and sweeping generalizations based on a completely irrelevant version of Scala ("a few years ago" == "not a version which would give any useful information to judge Scala today"), without being able to support any of it with even a glimpse of detail. At the same time, you come up with requirements where there is just no chance to actual fulfill them, e. g. bashing the language for both being not production-ready before 2.8 (is that even a point worth discussing?) and for rapidly improving on exactly these issues (OMG!!! It is changing too fast!). I think you should really make your mind up on these things, because you can't have it both ways. I'm saying this because this incoherent reasoning is constantly happening in your comments, it's not some isolated case.
- pron 12y ago
  > without being able to support any of it with even a glimpse of detail. I'm sorry, but you're just not getting it. I don't take issue with Scala's choice of square brackets over angled brackets. I take issue with the language philosophy and combined set of features. Here are the most detailed details: too many features, many of them overlapping (traits, structural types); too much complexity (type system, implicits); less readable; not enough constraints (e.g. immutability not enforced, casts allowed everywhere). That's as detailed as it gets. All in all, it came out benefits << cost. That's it. Either you don't want to understand or you think that when Boeing wants to write some big aircraft software thingy they say, "hmmm., the type inference is insufficient for our needs", or, "if only we had non-strict evaluation...". Because that's not how it works. In the industry languages are evaluated as a whole based on the project's criteria, with all their combined benefits weighed against their combined costs. This is what we've done. Scala came out lacking: too much overall cost for too little overall benefit. It was too complicated, too unconstraining, too unreadable, and too difficult to upgrade and build. What more do you want? > "not a version which would give any useful information to judge Scala today" No, I'm sorry, but you're just plain wrong! I gave up on Scala some years ago, but I can still tell its evolution has been in the opposite direction from what we wanted. Since then the language has become even bigger, more complex, more obtuse (collections) and even less constraining (macros). Even if the build and upgrade issues are better, the PL research philosophy is still there and its effects are only worse than they were some years ago.