4 ms·
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
by 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 agoBtw, 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 agoAfter 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 agoWhy do you say the Go community is toxic?
- epsylon 13y agoI for one think that the for comprehension syntax is more readable, especially when you start iterating over multiple sets.