From the article:<p><pre><code> val x = new Array[Integer](3) //type inferred for x
x(0) = 1
x(1) = 2
x(2) = 3
for (y <- x if y > 2)
println(y)
</code></pre>
The idiomatic way to do this is:<p><pre><code> val x = Array(1, 2, 3)
</code></pre>
That infers the type and sets values in one shot, with fewer characters. Also, using Integer (that's the java.lang.Integer) has been deprecated since 2.8.1 I believe. `Int` is preferred unless you really mean to use `Integer` (e.g. you're using a native Java library).
There are a number of syntactic errors and typos in the article. For instance `sum` should be:<p>* def sum(x: Int, y: Int) = x + y<p>Why `return x * y`? That is not a sum... Also using `return` is not idiomatic scala.<p>* List(1, 2, 3) ::: List(4, 5, 6)<p>That is the more typical way to concatenate lists. Using `+` will actually fail to compile.<p>* list.map(i => i + 1)<p>to increment the list. forall checks that a predicate is true for all elements.<p>And so on...
The article confuses immutability with being 'final' (both in Java and in Scala).<p>From the article:"In Java you can use the final keyword to differentiate variables that are not mutable. Scala has two keywords val and var to differentiate between mutable and immutable types."<p>If a variable is 'final' in Java, then the variable cannot be reassigned to another object once initialized. This does not at all prevent it from being used for a mutable object. For example:<p><pre><code> final Map<String, String> stateToCapital = new HashMap<String, String>();
// since HashMap is a mutable type, I can add a key/value pair:
stateToCapital.put("Indiana", "Indianapolis");
</code></pre>
Similarly in Scala, I could make a 'final' ('val' as opposed to 'var') assignment on a mutable data type:<p><pre><code> val myMutableMap = collection.mutable.Map("Indiana" -> "Indianapolis")</code></pre>
The features described are nice, but are they nice enough to make up for Scala often using more memory than Java and being a bit slower?<p>One data point: <a href="https://docs.google.com/open?id=0ByTAIYFOarh0cm9aSXlzc0NWaXc" rel="nofollow">https://docs.google.com/open?id=0ByTAIYFOarh0cm9aSXlzc0NWaXc</a><p>It is always about trade-offs, but you had the above with the much smaller functional language talent pool and I don't think I would want to use this are a core/shop language. If I was going to go functional, I think I'd go for Haskell GHC and get the functional lang benefits with better than Java performance.<p>Scala is definitely a good alt. lang for a Java shop though :)
"It is easy to notice that in Java, one might have implemented infinite number of for loops trying to do such lookups using iterators."<p>??<p>val list3 = list1 ::: list 2 // returns a new list of 6 elements<p>final list3 = new ArrayList(list1).addAll(list2);<p>list3.drop(2) //return a new list without first 2 elements<p>new ArrayList(list3.subList(2));<p>list3.filter(s => s > 4) //return a list with elements 5 and 6<p>new ArrayList(list3.subList(4));<p>Also the Java versions use standard convenience methods which seems preferable to language features since anyone can re-implement them, or add new ones. Plus the copy-on-mutate behaviour is optional.
This article focuses ONLY on minor syntactic differences. These are nice, but the things that will make all the difference are bigger issues, like the ability to easily write functional code (good) or incomprehensible type inference error messages (bad).