That was a good article. Generally I use Scala very little, but in the last few days I have written both Scala and Clojure wrappers for some of my Java code (I wanted idiomatic wrappers that feel Scala-like and Clojure-like - that is why I don't just directly call into Java).

Like Clojure, Scala could be a universal programming language for me if it was not for the learning curve: I have invested so many years on Lisp, Java, and Ruby that it is difficult to motivate myself to become proficient with 2 more languages.

Anyway, both the article and the comments to the article were interesting.

The primary barrier to entry for me in almost all programing languages were not the language constructs, but the libraries.

Considering you can use any java class in Scala or Clojure, I find them fairly easy to migrate to (though clojure is much more challenging due to the syntax and more pure functional nature).

The primary barrier for me is that every time I look at Scala, I think that this must be what a Perl and Java love child would look like. Granted, syntax isn't a (sole) reason to discount a language, but gawd some of the code examples look really obscure. I can't imagine trying to read it on a day to day basis, no matter how powerful.

I think Scala is more of a Java and Haskell/ML love child than anything else. Having used both of those, I found most of Scala pretty easy to pick up.

The main thing I found is that there are a lot more syntactic constructions you have to be familiar with than in most other languages, because Scala borrows a lot from ML-like functional languages but doesn't really leave much out from Java, and then adds a few things along the way.

If you are not too familiar with functional paradigms, many of the code examples seems obscurely clever. The nice thing about Scala is there is always a procedural way of doing the same operation that is more digestible for most people. I find the trend in developers coming to Scala from languages like Java/Ruby/Python/etc is to begin with the latter and gradually improve technique toward the former.

my primary barrier is maven (I'm coming from Ruby and gems).

I wonder why the sbaz (Scala-Bazaar package manager) is not the default, rather than maven.

In theory you can use any Java class/library. However, in practice this can be quite painful, given the type conversions you'll have to do everywhere the two touch. There are 'implicit' conversions for many base types, but when it gets a bit more complex, you'll have to write your own conversions, especially from Scala->Java.

> While you can’t get code into your templates, it’s easy to get UI into your code, which is (almost) just as bad.

I looked at Lift a year or two ago and this was the showstopper for me. While there's a cleanliness and purity to rigidly enforced templating I have never developed a web app where I didn't need some kind of creative "UI" logic somewhere. If you can't put it in the templates then it doesn't go away ... it goes into your core code where the poor schmuck looking at the template has no hope of doing anything with it. For me, putting what is otherwise pure UI logic in the UI layer is a lesser evil than having it permeate back to the middle tier or "view" code layer.

    def sum = series.map(_.sum).foldLeft(0.0)(_+_)

Gah, no, stop. Remember, kids: everytime you use naive map-reduce for floating point arithmetic operations, God kills a kitten.

I personally didn't realize this was that inefficient. Can someone give the preferable alternative?

It's not an efficiency issue. Adding floating point numbers naively left-to-right can introduce huge errors, even in small data sets.

http://en.wikipedia.org/wiki/Floating_point#Accuracy_problem...

But is not limited to map/reduce... every time you use floating point god kills a kitten

In a perfect world, a compiler would optimize this code to be equivalent to summing in a simple loop, at least if series were a projection or had a non-strict map function. Whether scalac and the JVM can work together to do this right now or not is beyond my knowledge. Hopefully specialization in Scala 2.8 will at least get the JVM one major step closer.

Summing floating point numbers in a simple loop is just as bad. It's not an issue of efficiency, it's an issue of accuracy.

I guess I've been causing the death of kittens for a while then. I couldn't, however, deduce from your wikipedia link or from a quick google search what the correct way of adding floating point numbers should be, though. Even the MS compiler guys at http://msdn.microsoft.com/en-us/library/aa289157%28VS.71%29.... are writing code snippets that sum floating point numbers in a loop.

edit: You're write jfager. I didn't read the article I linked to very carefully. The article actually has an example algorithm, the Kahan sum, for reducing the error caused by summing floating point numbers in a loop!

The whole point of the article you linked to is how to avoid summing floating point numbers in a simple loop.

Using scala almost daily, I don't think I have ever done that, with floating point anyway - looks like one line slideware code for demos.

I share many of the author's feelings with one notable exception. He praises testing libraries in his pros section. While they show promise, I find these libraries to be in need of maturing. This is obviously true for much of the Scala ecosystem, but in my opinion, the have progressed a bit more slowly than other components I have used.