5 ms·

> If needed, you can mostly stick to the imperative side of Scala and slowly work in more functional features as well as some of the useful syntactical sugar st

> If needed, you can mostly stick to the imperative side of Scala and slowly work in more functional features as well as some of the useful syntactical sugar stuff (like operator overloading) that Scala provides I'd say that's a bad idea. People keep saying that Scala is not an opinionated language and that you have to make choices and stuff. That's not true and in fact, Scala is a very opinionated language that makes imperative code painful. That's why some beginners get so frustrated when they pick it up. Because they come with certain wrong assumptions about how features in Scala work. Examples: Scala does not have "break" or "continue", while "return" does not behave as many people think it behaves. The "yield" keyword in "for" expressions is also totally different than the "yield" in C# or Python or Ruby. Actually "for" expressions in themselves are actually monad comprehensions - powerful, elegant, but definitely not your grandma's foreach. Also, collections are immutable by default.

saryant 13y ago
> Actually "for" expressions in themselves are actually monad comprehensions - powerful, elegant, but definitely not your grandma's foreach. Also, collections are immutable by default. This definitely threw me for a loop when I started using Scala. I banged my head against the keyboard a few times trying to get for comprehensions to do what I thought they should do. Once I began to fully understand the relationship between for comprehensions and monadic operations, especially on Futures and Options, I began to understand their power.
yareally 13y ago
You have a point in that the features may not be one to one equivalents, though that's generally the case when using any new language to a point. Even Java to C# vary a bit for their overlapping keywords/features. Yield might return a collection in Scala instead of an iterator like in Python, but that's not a huge knowledge leap to wrap one's head around. Are collections immutable by default in Scala? I thought each each was treated as a separate, but equal package (scala.collection.mutable and scala.collection.immutable) and collections within scala.collection itself can be either mutable or immutable since they're super-classes to both subpackages. The difference between the super-package collections and the subpackage collections.immutable being that collections.immutable was guaranteed to be immutable. I've kind of avoided "yield" so far and opted for the functional equivalents. Something like val result: Array[Int] = for (elem ← n if n % 2 == 0) yield 5 * elem just looks more readable as: val result = n.filter(_ % 2 == 0).map(5 * _) or in more functional syntax: val result = n filter { _ % 2 == 0 } map { 5 * _ } I don't think imperative code is necessarily painful in Scala, it's just constructed a bit differently. On the other side of the paradigm, functional language advocates seem to say functional programming in it is also painful[1]. Just seems Scala cannot 100% please everyone 100% of the time. [1] https://groups.google.com/d/msg/scala-functional/kvbaE6cAzqM/RC1nmc-HUtYJ https://groups.google.com/d/msg/scala-functional/kvbaE6cAzqM...
- bad_user 13y ago
  Btw, regarding for-comprehensions and Futures, there's a new project that's going to make things interesting for working with Futures: https://github.com/scala/async https://github.com/scala/async > On the other side of the paradigm, functional language advocates seem to say functional programming in it is also painful[1] Worth pointing out that the people advocating for a better language in that thread, including the one that started it, have problems with Haskell too (currently the poster child for functional programming). It is the reason why many of them are using Scala, whether they like to admit it or not. In that thread it is even argued that lambda-calculus itself is outdated because it is inherently sequential. Scala attracted many idealists that aren't pleased with any mainstream language. On one hand it is good, because it moves the language forward. By comparison the Go community is kind of toxic. On the other hand, people that don't get the context of that discussion jump to conclusions.
  - yareally 13y ago
    After going back and rereading some of the posts, I agree without you about it having a group of angry programmers that aren't happy no matter what they get. That project looks interesting though. Looks like it's almost based on the new async abilities in C# 5.0[1]. Have you tried it any yet in Scala? [1] http://fizzylogic.nl/2012/05/04/adding-asyncawait-support-to-your-mono-for-android-projects/ http://fizzylogic.nl/2012/05/04/adding-asyncawait-support-to...
  - swah 13y ago
    Why do you say the Go community is toxic?
- epsylon 13y ago
  I for one think that the for comprehension syntax is more readable, especially when you start iterating over multiple sets.

saryant 13y ago

> Actually "for" expressions in themselves are actually monad comprehensions - powerful, elegant, but definitely not your grandma's foreach. Also, collections are immutable by default. This definitely threw me for a loop when I started using Scala. I banged my head against the keyboard a few times trying to get for comprehensions to do what I thought they should do. Once I began to fully understand the relationship between for comprehensions and monadic operations, especially on Futures and Options, I began to understand their power.

yareally 13y ago

You have a point in that the features may not be one to one equivalents, though that's generally the case when using any new language to a point. Even Java to C# vary a bit for their overlapping keywords/features. Yield might return a collection in Scala instead of an iterator like in Python, but that's not a huge knowledge leap to wrap one's head around. Are collections immutable by default in Scala? I thought each each was treated as a separate, but equal package (scala.collection.mutable and scala.collection.immutable) and collections within scala.collection itself can be either mutable or immutable since they're super-classes to both subpackages. The difference between the super-package collections and the subpackage collections.immutable being that collections.immutable was guaranteed to be immutable. I've kind of avoided "yield" so far and opted for the functional equivalents. Something like val result: Array[Int] = for (elem ← n if n % 2 == 0) yield 5 * elem just looks more readable as: val result = n.filter(_ % 2 == 0).map(5 * _) or in more functional syntax: val result = n filter { _ % 2 == 0 } map { 5 * _ } I don't think imperative code is necessarily painful in Scala, it's just constructed a bit differently. On the other side of the paradigm, functional language advocates seem to say functional programming in it is also painful[1]. Just seems Scala cannot 100% please everyone 100% of the time. [1] https://groups.google.com/d/msg/scala-functional/kvbaE6cAzqM/RC1nmc-HUtYJ https://groups.google.com/d/msg/scala-functional/kvbaE6cAzqM...

bad_user 13y ago
Btw, regarding for-comprehensions and Futures, there's a new project that's going to make things interesting for working with Futures: https://github.com/scala/async https://github.com/scala/async > On the other side of the paradigm, functional language advocates seem to say functional programming in it is also painful[1] Worth pointing out that the people advocating for a better language in that thread, including the one that started it, have problems with Haskell too (currently the poster child for functional programming). It is the reason why many of them are using Scala, whether they like to admit it or not. In that thread it is even argued that lambda-calculus itself is outdated because it is inherently sequential. Scala attracted many idealists that aren't pleased with any mainstream language. On one hand it is good, because it moves the language forward. By comparison the Go community is kind of toxic. On the other hand, people that don't get the context of that discussion jump to conclusions.
- yareally 13y ago
  After going back and rereading some of the posts, I agree without you about it having a group of angry programmers that aren't happy no matter what they get. That project looks interesting though. Looks like it's almost based on the new async abilities in C# 5.0[1]. Have you tried it any yet in Scala? [1] http://fizzylogic.nl/2012/05/04/adding-asyncawait-support-to-your-mono-for-android-projects/ http://fizzylogic.nl/2012/05/04/adding-asyncawait-support-to...
- swah 13y ago
  Why do you say the Go community is toxic?
epsylon 13y ago
I for one think that the for comprehension syntax is more readable, especially when you start iterating over multiple sets.