3 ms·

> you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable. Sure, I could nam

> you might want to name actual things that you don't like, as in things that you can talk about, instead of things that are non-falsifiable. Sure, I could name things that I don't like but they will be by definition non falsifiable as well, so I don't really see the point of what you're asking. Overall, I just find the surface area of Scala way, way too big. I felt the same way about C++ compared to C in the 90s, hence my comparison. I've used Scala for five years and over that period of time, I've seen the language adding feature over feature instead of addressing critical aspects such as good IDE support or decent build tools. I'm still stuck with Scala at work but I'm really hoping Kotlin takes off because using it on my personal projects has been a breath of fresh air compared to Scala. It's like getting 90% of the power of Scala with 5% of the cognitive load.

whateveracct 11y ago
Scala's surface area isn't especially large though? Here's a list of Scala language-specific features I use & have to keep in my head on a daily basis: - Case classes + sealed hierarchies (algebraic types, in other words) - Implicit parameters - Collections library - Traits - Function types, currying, partial application - for-yield - Pattern matching None of those concepts on their own are especially complicated. In fact, I find Scala to have a bunch of orthogonal features that are easy to understand on their own and that compose in a variety of useful ways.
- incepted 11y ago
  > Scala's surface area isn't especially large though? You'll find plenty of disagreement with that feeling everywhere you ask... The fact that you choose to use a small subset of all these features is irrelevant: eventually, you have to hold all the language in your head because you will work with other people and other organizations that have different standards than you do. Which is why it's so important for a language to learn how to say "no" to new features, something I feel Scala has been unable to do.
  - whateveracct 11y ago
    What other features could someone even reasonably use though? I say this because what I listed above isn't some small subset of Scala. It's actually the majority of the language. Hmm I'll try to think of some features that we don't use at work that would add additional semantic overhead: - Inheritance? I mean okay but nobody I work with makes heavy use of this anyways and if I were working in a Scala shop where inheritance was used heavily it would be like working in a different language. So I suppose I'll give you that although I don't see how that makes the language hard to learn or work with. - Mutable collections + references (vars)? Once again nobody I work with uses these outside of local mutability when they fail to be able to leverage immutable abstractions that do the same thing. If I worked in a Scala shop where mutability was used without care, it would be like working in a different language entirely true. - while loops? I don't know what else I'm grasping for straws here. If anything, the additional 'complicated' things we use in Scala aren't language features but rather libraries, mostly scalaz/shapeless.
    - dragonwriter 11y ago
      > If anything, the additional 'complicated' things we use in Scala aren't language features but rather libraries One thing with Scala is that various features of the language allow libraries to reshape the "feel" of the language, because a number of things that would be fixed in the language in many other languages can be modified by libraries in Scala.
      - mike_hearn 11y ago
        Consider that whilst Kotlin does not support things like function currying and partial application out of the box, they can both be added by a library (funktionale). Kotlin has a focus on DSLs defined in libraries and has a few language features that are intended to make them work better, in this sense, Kotlin and Scala are similar.
        dragonwriter 11y ago
        Right, but by comparison Scala goes further than Kotlin on this. Consider the case of operators, for instance: Kotlin, like many languages, lets you redefined a predefined set of operators for new types with predefined precedence, Scala lets you create entirely new operators. To some, this is a strength for Scala -- to others, it is a weakness.
whateveracct 11y ago
Also IDE support in Scala is pretty much fine. Have you used it lately? IntelliJ is able to handle my code fine in almost all cases, and I make heavy use of scalaz and occasionally what Scala has for dependent types. The only problems I ever run into are IntelliJ sometimes telling me I don't use an import for a typeclass instance that I am definitely using.
- narrator 11y ago
  I love Scala but the Intellij support is lacking in that it can't always find the right import to auto-import and I have to manually add it myself. I think it comes down to the fact that it takes the compiler a lot of cpu cycles to figure out what's actually in scope with implicits, etc. I soldier through it, but it can be annoying when I have to go hunting around for the import.
  - bad_user 11y ago
    IntelliJ IDEA's auto-import works fine for normal imports. But it cannot guess what implicits you need imported in scope any more than the compiler can. The only implicit (I can think of) from the standard library that needs to be explicitly imported is ExecutionContext.Implicits.global. It's a form of dependency injection meant for working with Future and the error message tells you exactly what to do, but it can't be automatically imported because the thread-pool used is a pretty big deal and you should pause for a second to think about it. Other than that, the implicits you need are probably your own doing, because common libraries usually have a design where you get everything needed with sensible defaults. In other words, if it's painful to import, then you should probably rethink it. This is actually a very good rule for Java as well. People too often rely on IDEs to do the boring parts, not noticing the stench until it is too late.
    - draven 11y ago
      As said on http://www.scala-lang.org/api/2.11.7/index.html#scala.concurrent.ExecutionContext http://www.scala-lang.org/api/2.11.7/index.html#scala.concur... the default global should not be imported all over the place. It's better to declare functions with an implicit ExecutionContext and try to declare your execution contexts in a few well-known places. The (web) app I'm working on uses several ExecutionContexts (database access has a specific one for example.)
bad_user 11y ago
Here's the reason for why I asked. You're saying that: > I've seen the language adding feature over feature instead of addressing critical aspects such as good IDE support or decent build tools Well, Scala 2.11 hasn't added any features, being a release meant for stabilizing, modularizing and optimizing the compiler and the library, fixing many non-withstanding issues. So zero new features. Scala 2.10, released Jan/04-2013 (2 and a half years ago, OK?), was the release that added some features which included Value Classes / Implicit Classes (they are linked, for providing extension methods, as a refinement of implicit conversions), String interpolation (any sane language has it, plus Scala can now deprecate the conversion to String that was imported from Java), plus macros as experimental. Besides macros, everything else is minor and macros are meant for library authors as a neater way of building compiler plugins. Scala 2.9, released May/12-2011, only includes changes to the standard library and not the language. Scala 2.8, released Jul/14-2010 (5 years ago), introduced named and default arguments, package objects, changes to implicits, type constructor inference and a completely redesigned collections library. This release was so big for its users that it should have been called Scala 3. Before Scala 2.8 the language wasn't suitable for usage and Scala 2.11 is pretty much the same language as Scala 2.8. So I'm really wondering what "feature after feature" you're referring to. Really, take other programming languages that aren't Java and compare the features added in the last 5 years to Scala's history. You'll have a surprise ;-) Also IntelliJ IDEA is pretty awesome for Scala, I've been using it for the last 3 years. It's worse than IntelliJ IDEA for Java, but it is better than Eclipse for Java or Visual Studio for C#. There's also Scala IDE (built on top of Eclipse) and Ensime (a pretty capable Emacs / Atom / SublimeText plugin). Other platforms can only dream of such support, including Kotlin, or C# for that matter. I'm not joking. > Sure, I could name things that I don't like So why don't you name those things that you don't like?
- incepted 11y ago
  > So why don't you name those things that you don't like? Because then you will tell me that I don't like these features because I don't understand them? But alright, here are a few: - The type projector lambda syntax is absurdly arcane: `({type λ[α] = Either[A, α]})#λ]` - The curry syntax is silly as well (multiple parentheses) - The "_" character has eleven different meanings depending on where it's used [1] [1] http://stackoverflow.com/questions/8000903/what-are-all-the-uses-of-an-underscore-in-scala http://stackoverflow.com/questions/8000903/what-are-all-the-...

whateveracct 11y ago

Scala's surface area isn't especially large though? Here's a list of Scala language-specific features I use & have to keep in my head on a daily basis: - Case classes + sealed hierarchies (algebraic types, in other words) - Implicit parameters - Collections library - Traits - Function types, currying, partial application - for-yield - Pattern matching None of those concepts on their own are especially complicated. In fact, I find Scala to have a bunch of orthogonal features that are easy to understand on their own and that compose in a variety of useful ways.

incepted 11y ago
> Scala's surface area isn't especially large though? You'll find plenty of disagreement with that feeling everywhere you ask... The fact that you choose to use a small subset of all these features is irrelevant: eventually, you have to hold all the language in your head because you will work with other people and other organizations that have different standards than you do. Which is why it's so important for a language to learn how to say "no" to new features, something I feel Scala has been unable to do.
- whateveracct 11y ago
  What other features could someone even reasonably use though? I say this because what I listed above isn't some small subset of Scala. It's actually the majority of the language. Hmm I'll try to think of some features that we don't use at work that would add additional semantic overhead: - Inheritance? I mean okay but nobody I work with makes heavy use of this anyways and if I were working in a Scala shop where inheritance was used heavily it would be like working in a different language. So I suppose I'll give you that although I don't see how that makes the language hard to learn or work with. - Mutable collections + references (vars)? Once again nobody I work with uses these outside of local mutability when they fail to be able to leverage immutable abstractions that do the same thing. If I worked in a Scala shop where mutability was used without care, it would be like working in a different language entirely true. - while loops? I don't know what else I'm grasping for straws here. If anything, the additional 'complicated' things we use in Scala aren't language features but rather libraries, mostly scalaz/shapeless.
  - dragonwriter 11y ago
    > If anything, the additional 'complicated' things we use in Scala aren't language features but rather libraries One thing with Scala is that various features of the language allow libraries to reshape the "feel" of the language, because a number of things that would be fixed in the language in many other languages can be modified by libraries in Scala.
    - mike_hearn 11y ago
      Consider that whilst Kotlin does not support things like function currying and partial application out of the box, they can both be added by a library (funktionale). Kotlin has a focus on DSLs defined in libraries and has a few language features that are intended to make them work better, in this sense, Kotlin and Scala are similar.
      - dragonwriter 11y ago
        Right, but by comparison Scala goes further than Kotlin on this. Consider the case of operators, for instance: Kotlin, like many languages, lets you redefined a predefined set of operators for new types with predefined precedence, Scala lets you create entirely new operators. To some, this is a strength for Scala -- to others, it is a weakness.

whateveracct 11y ago

Also IDE support in Scala is pretty much fine. Have you used it lately? IntelliJ is able to handle my code fine in almost all cases, and I make heavy use of scalaz and occasionally what Scala has for dependent types. The only problems I ever run into are IntelliJ sometimes telling me I don't use an import for a typeclass instance that I am definitely using.

narrator 11y ago
I love Scala but the Intellij support is lacking in that it can't always find the right import to auto-import and I have to manually add it myself. I think it comes down to the fact that it takes the compiler a lot of cpu cycles to figure out what's actually in scope with implicits, etc. I soldier through it, but it can be annoying when I have to go hunting around for the import.
- bad_user 11y ago
  IntelliJ IDEA's auto-import works fine for normal imports. But it cannot guess what implicits you need imported in scope any more than the compiler can. The only implicit (I can think of) from the standard library that needs to be explicitly imported is ExecutionContext.Implicits.global. It's a form of dependency injection meant for working with Future and the error message tells you exactly what to do, but it can't be automatically imported because the thread-pool used is a pretty big deal and you should pause for a second to think about it. Other than that, the implicits you need are probably your own doing, because common libraries usually have a design where you get everything needed with sensible defaults. In other words, if it's painful to import, then you should probably rethink it. This is actually a very good rule for Java as well. People too often rely on IDEs to do the boring parts, not noticing the stench until it is too late.
  - draven 11y ago
    As said on http://www.scala-lang.org/api/2.11.7/index.html#scala.concurrent.ExecutionContext http://www.scala-lang.org/api/2.11.7/index.html#scala.concur... the default global should not be imported all over the place. It's better to declare functions with an implicit ExecutionContext and try to declare your execution contexts in a few well-known places. The (web) app I'm working on uses several ExecutionContexts (database access has a specific one for example.)

bad_user 11y ago

Here's the reason for why I asked. You're saying that: > I've seen the language adding feature over feature instead of addressing critical aspects such as good IDE support or decent build tools Well, Scala 2.11 hasn't added any features, being a release meant for stabilizing, modularizing and optimizing the compiler and the library, fixing many non-withstanding issues. So zero new features. Scala 2.10, released Jan/04-2013 (2 and a half years ago, OK?), was the release that added some features which included Value Classes / Implicit Classes (they are linked, for providing extension methods, as a refinement of implicit conversions), String interpolation (any sane language has it, plus Scala can now deprecate the conversion to String that was imported from Java), plus macros as experimental. Besides macros, everything else is minor and macros are meant for library authors as a neater way of building compiler plugins. Scala 2.9, released May/12-2011, only includes changes to the standard library and not the language. Scala 2.8, released Jul/14-2010 (5 years ago), introduced named and default arguments, package objects, changes to implicits, type constructor inference and a completely redesigned collections library. This release was so big for its users that it should have been called Scala 3. Before Scala 2.8 the language wasn't suitable for usage and Scala 2.11 is pretty much the same language as Scala 2.8. So I'm really wondering what "feature after feature" you're referring to. Really, take other programming languages that aren't Java and compare the features added in the last 5 years to Scala's history. You'll have a surprise ;-) Also IntelliJ IDEA is pretty awesome for Scala, I've been using it for the last 3 years. It's worse than IntelliJ IDEA for Java, but it is better than Eclipse for Java or Visual Studio for C#. There's also Scala IDE (built on top of Eclipse) and Ensime (a pretty capable Emacs / Atom / SublimeText plugin). Other platforms can only dream of such support, including Kotlin, or C# for that matter. I'm not joking. > Sure, I could name things that I don't like So why don't you name those things that you don't like?

incepted 11y ago
> So why don't you name those things that you don't like? Because then you will tell me that I don't like these features because I don't understand them? But alright, here are a few: - The type projector lambda syntax is absurdly arcane: `({type λ[α] = Either[A, α]})#λ]` - The curry syntax is silly as well (multiple parentheses) - The "_" character has eleven different meanings depending on where it's used [1] [1] http://stackoverflow.com/questions/8000903/what-are-all-the-uses-of-an-underscore-in-scala http://stackoverflow.com/questions/8000903/what-are-all-the-...