5 ms·

M'eh. Yes, Scala has flaws but I feel like this talk makes too much of minor annoyances. Ultimately you make an engineering decision about platform. Do you want

M'eh. Yes, Scala has flaws but I feel like this talk makes too much of minor annoyances. Ultimately you make an engineering decision about platform. Do you want decent performance, lotsa libraries, and a modern statically typed language? Scala is arguably your best option at present (yes this can be argued with; no that isn't an interesting argument to have). Maybe we'll all be using Rust/Haskell/whatever in 5 years, but in the meantime I got code to write and products to build and I'm using Scala for better or worse. Specifically: - Code on slide 3 has typos. (Yeah, that's minor) - Lambdas are slower than Java 8 -- that's because Scala currently supports Java 6+. Java 8 has been released for 6 months. This is a ridiculous complaint. - Heavy in terms of concepts -- another ridiculous complaint. If you want to keep on writing Java, keep writing Java. If Scala didn't bring new stuff to the table it wouldn't be interesting. - Implicits -- agreed they can be misused. Type classes are the way forward. - I don't understand many of the "very ugly" complaints. Yes, collections have lots of methods. Is this surprising? Yes, library code may be written in an abstract way. So what? Yes, DSLs look like DSLs. Yes, abstracting over arity is a problem in all statically typed languages. etc. There are valid complaints to be made about Scala. I feel this talk demonstrates a lack of understanding of the language, and many of its complaints are in fact misunderstandings. To me the biggest issue this talk reveals is that if you come from an OO background (which I assume the author does) then learning Scala will require a change of mindset. I don't think it is fair to make this a language complaint though. Scala makes it fairly obvious what you're getting yourself into and, as I said above, if you wanted to keep on writing code the way you have in the past it's not clear why you are using Scala in the first place.

bozho 12y ago
There is a point in my presentation that says that some of these annoyances are easy to overcome in a real project. But some of them aren't. As for the misunderstandings - the "bad" parts are ..bad. The ugly parts may not be bad, but are ugly (which is subjective, and I think it's implied it's subjective)
- noelwelsh 12y ago
  Perhaps the issue is that the slides don't really stand on their own. Without hearing what you have to say for many of the slides it is difficult to really get the point you're making. Let me just address the "bad" slides, and what I got from them. Slide 8 - Compiler too slow. A common complaint. Agreed it could be faster. - Ecosystem. Don't really get the point here. Yes, Scala has different idioms to Java, so naturally Java libraries don't make for idiomatic Scala code. There are many mature Scala libraries. Binary incompatibility has not been a problem for me in at least two years, and it is a necessary artifact of Scala compiling a language that is not Java to JVM bytecode. - Lambdas I addressed above. Slide 9 Don't know what point you're making here. Slide 10 Mostly addressed above. Syntax doesn't bother me. There are regular rules and the alternatives are a consequence of those regular rules. Would consider removing eta-expansion. Never had an issue with any of the rules though. Slide 11 See above. Slide 12 See above on type classes. Slide 13 This is very generic. Applies to all languages. Slide 14-15 Don't really get it. You can write code in many different ways. Applies to all languages. Slide 16 This is very generic. Applies to all languages. Slide 17 Don't get the point you're trying to make with this code. Slide 18 This is presumably a slide that summarises this section. Without hearing what you have to say here I can't really interpret this.
weego 12y ago
Scala gives you an excellent way to go about changing your mindset though. I feel like functional logic at a granular level wrapped in OO structures is a very logical way to go about building the kinds of software that Scala is being used for.
pron 12y ago
> If you want to keep on writing Java, keep writing Java. Ah! But that’s the point, because Scala is pulling a bait-and-switch. If it were only a modern statically typed language I wouldn’t complain so much about it (and I really do complain a lot about Scala, I guess). Yes, I find its gaudy indiscrimination aesthetically unpleasing[1], but that’s a matter of personal taste. The problem is that Scala still markets itself as “a better Java”, and people are drawn to it so they wouldn't have to write getters and constructors. And at first, Scala does seem to be that. Only after a while you realize that it’s a whole other beast altogether — not necessarily the one you bought into. If Scala were marketed as “a JVM language Haskellers can learn to live with”, I’d have no issue with it (except the aesthetics, that is :)). [1]: Yet, with its near-infinite list of features it can't even type immutability, which even Java 8 can through its pluggable type systems.
- noelwelsh 12y ago
  Indeed, if Scala wasn't closely compatible with Java (in terms of both syntax and interop) it would not have so much traction. That's the deal with the devil that Scala made, and one reason it has an excess of cruft. For example, no language needs both traits and abstract classes, unless that language wants to interoperate easily with Java. I am broadly agreed with you. Scala could do with trimming, and I'm optimistic that both Typelevel and Typesafe will accomplish this in the near future.
  - anentropic 12y ago
    " For example, no language needs both traits and abstract classes, unless that language wants to interoperate easily with Java." now I'm wondering - does Clojure then suffer the same crufting? or it's less interoperable?
    - noelwelsh 12y ago
      I believe Clojure is less directly interoperable. For instance, a Scala class is a Java class. I believe creating a Java class in Clojure is something you have to call into a library to do. Update: reading the Clojure docs, the main issue I see is compiling Java code against Clojure code. Clojure has a number of constructs for calling Java code and creating Java objects, but it's not clear to me how you define an API in Clojure that Java code can then call.
jimbokun 12y ago
"I don't understand many of the "very ugly" complaints. Yes, collections have lots of methods. Is this surprising?" Perhaps "very ugly" refers to method names like "/:". (Example on slide 22. There are many more examples of "very ugly" in that slide, too.) This reflects on the culture, not the language, but it means in practice you will need to read lots of code with random punctuation used for method and function names. Unless you never use any libraries and never work with other Scala developers who write code like this.
- buddhu 12y ago
  "... in practice you will need to read lots of code with random punctuation used for method and function names." In my two or so years of Scala I've yet to see anyone actually use /: or similarly named methods, and if they did I would make sure it never gets past a code review. Yes, the methods are still there, but in my experience people avoid them (even Odersky thinks they were a bad idea), and libraries with a lot of symbolic methods (Scalaz, and everyone's favorite whipping boy, Dispatch) are not particularly mainstream. So my experience at least has been the opposite of what you assert. I would instead say that "... in practice you will NOT need to read lots of code with random punctuation used for method and function names."
GeoffKnauth 12y ago
Amen, brother.

bozho 12y ago

There is a point in my presentation that says that some of these annoyances are easy to overcome in a real project. But some of them aren't. As for the misunderstandings - the "bad" parts are ..bad. The ugly parts may not be bad, but are ugly (which is subjective, and I think it's implied it's subjective)

noelwelsh 12y ago
Perhaps the issue is that the slides don't really stand on their own. Without hearing what you have to say for many of the slides it is difficult to really get the point you're making. Let me just address the "bad" slides, and what I got from them. Slide 8 - Compiler too slow. A common complaint. Agreed it could be faster. - Ecosystem. Don't really get the point here. Yes, Scala has different idioms to Java, so naturally Java libraries don't make for idiomatic Scala code. There are many mature Scala libraries. Binary incompatibility has not been a problem for me in at least two years, and it is a necessary artifact of Scala compiling a language that is not Java to JVM bytecode. - Lambdas I addressed above. Slide 9 Don't know what point you're making here. Slide 10 Mostly addressed above. Syntax doesn't bother me. There are regular rules and the alternatives are a consequence of those regular rules. Would consider removing eta-expansion. Never had an issue with any of the rules though. Slide 11 See above. Slide 12 See above on type classes. Slide 13 This is very generic. Applies to all languages. Slide 14-15 Don't really get it. You can write code in many different ways. Applies to all languages. Slide 16 This is very generic. Applies to all languages. Slide 17 Don't get the point you're trying to make with this code. Slide 18 This is presumably a slide that summarises this section. Without hearing what you have to say here I can't really interpret this.

weego 12y ago

Scala gives you an excellent way to go about changing your mindset though. I feel like functional logic at a granular level wrapped in OO structures is a very logical way to go about building the kinds of software that Scala is being used for.

pron 12y ago

> If you want to keep on writing Java, keep writing Java. Ah! But that’s the point, because Scala is pulling a bait-and-switch. If it were only a modern statically typed language I wouldn’t complain so much about it (and I really do complain a lot about Scala, I guess). Yes, I find its gaudy indiscrimination aesthetically unpleasing[1], but that’s a matter of personal taste. The problem is that Scala still markets itself as “a better Java”, and people are drawn to it so they wouldn't have to write getters and constructors. And at first, Scala does seem to be that. Only after a while you realize that it’s a whole other beast altogether — not necessarily the one you bought into. If Scala were marketed as “a JVM language Haskellers can learn to live with”, I’d have no issue with it (except the aesthetics, that is :)). [1]: Yet, with its near-infinite list of features it can't even type immutability, which even Java 8 can through its pluggable type systems.

noelwelsh 12y ago
Indeed, if Scala wasn't closely compatible with Java (in terms of both syntax and interop) it would not have so much traction. That's the deal with the devil that Scala made, and one reason it has an excess of cruft. For example, no language needs both traits and abstract classes, unless that language wants to interoperate easily with Java. I am broadly agreed with you. Scala could do with trimming, and I'm optimistic that both Typelevel and Typesafe will accomplish this in the near future.
- anentropic 12y ago
  " For example, no language needs both traits and abstract classes, unless that language wants to interoperate easily with Java." now I'm wondering - does Clojure then suffer the same crufting? or it's less interoperable?
  - noelwelsh 12y ago
    I believe Clojure is less directly interoperable. For instance, a Scala class is a Java class. I believe creating a Java class in Clojure is something you have to call into a library to do. Update: reading the Clojure docs, the main issue I see is compiling Java code against Clojure code. Clojure has a number of constructs for calling Java code and creating Java objects, but it's not clear to me how you define an API in Clojure that Java code can then call.

jimbokun 12y ago

"I don't understand many of the "very ugly" complaints. Yes, collections have lots of methods. Is this surprising?" Perhaps "very ugly" refers to method names like "/:". (Example on slide 22. There are many more examples of "very ugly" in that slide, too.) This reflects on the culture, not the language, but it means in practice you will need to read lots of code with random punctuation used for method and function names. Unless you never use any libraries and never work with other Scala developers who write code like this.

buddhu 12y ago
"... in practice you will need to read lots of code with random punctuation used for method and function names." In my two or so years of Scala I've yet to see anyone actually use /: or similarly named methods, and if they did I would make sure it never gets past a code review. Yes, the methods are still there, but in my experience people avoid them (even Odersky thinks they were a bad idea), and libraries with a lot of symbolic methods (Scalaz, and everyone's favorite whipping boy, Dispatch) are not particularly mainstream. So my experience at least has been the opposite of what you assert. I would instead say that "... in practice you will NOT need to read lots of code with random punctuation used for method and function names."

GeoffKnauth 12y ago

Amen, brother.