
Scala for the Impatient, by Cay Horstmann (introductory)
Scala in Depth, by Joshua Suereth (advanced)
The Introduction from scala-lang.org and a Tour of Scala are not good introductions. They are meant as a TL;DR that will leave you scratching your head and reading the list of features without the larger context of a language is an awful way to learn about that language.
IntelliJ IDEA with the Scala plugin is a good IDE, but the article should have included a link to the Scala-IDE plugin for Eclipse. It's not friendly for beginners to make them install a plugin, which is why Typesafe is already providing a download of a completely configured Eclipse here: http://typesafe.com/stack/scala_ide_download
Also, when starting out with a language I would rather use a plain text editor and the compiler directly, because complicated tools bring with them complicated problems ... Hello World with just the compiler is just one text file that you can directly execute, versus the notion of whatever a project is in an IDE. And you should start with the REPL anyway.
"Scala for Java Refugees" is an article series that's out of date and not that good frankly. There already is a comment here from somebody saying he was scared when he saw in that series the usage of implicit conversions - a feature that in Scala 2.10 is considered experimental, for really advanced use-cases and that has to be enabled manually, as for most purposes there are better solutions available - but on the other hand, the context of a feature matters a lot. Implicit conversions are great for dealing with the "expression problem" and through their means, Arrays (a fundamental JVM data-structure with a broken interface) behave like plain Seqs in Scala, while Strings are considered to be lists of chars (as in Haskell or Lisp).
I didn't like Alex Payne's "Programming Scala" book. It's boring, it's poorly organized and it's out of date - for instance a big part of it involves dealing with Scala's Actors, but Scala's Actors were terrible, which is why in Scala 2.10 the implementation in the standard library gets replaced with Akka, which is the defacto standard anyways, but it also has a slightly different API and concepts. Actors are also the kind of powerful construct that's not easy to tame, being an awful way to start learning Scala ... before Akka Actors, look into Scala's Parallel collections, or into Akka's Futures and Promises or into ScalaSTM.
Speaking of Parallel Collections and Futures and Promises, no mention of Scala's Documentation project?
http://docs.scala-lang.org/overviews/
A much better introduction to the language is "Scala for the Impatient", a book that wasn't mentioned and one third of the book (enough to get you started) is available from Typesafe's website: http://blog.typesafe.com/free-pdf-from-typesafe-scala-for-th...
You also cannot write about learning resource, without mentioning "Programming in Scala" by Odersky, a wonderful book also meant for human beings. Its only problem is that it's a tome of information and you may not have the patience for that, but it's not a hard to digest book so if you've got the time and patience, then this is THE book you should read: http://www.artima.com/shop/programming_in_scala_2ed
And you must also mention "Scala in Depth" by Joshua Suereth, which is like the equivalent of "Effective Java", a ~ 300-pages book you definitely must read once you're done with "Scala for the Impatient": http://www.manning.com/suereth/
On the other hand the Coursera Course taught by Odersky on Function Programming is awesome. I've took it and it was worth every minute of it.
Very true, except that it doesn't happen in practice.
There's a more elaborate discussion in Joshua Suereth's book "Scala in Depth" on this very topic, because Scala has the exact same problem. A boatload of OO Java guys are now migrating to Scala, bringing their OO with them. Teaching them Scala is trivial, teaching them FP is not.
The example Joshua gives is "a cat catches a bird and eats it".
How should programmers model that ?
What programmers should do is focus on the verbs. So first define a catch function and an eat function. Then compose them like this: catch(...) andThen eat(...). Define a Cat trait and a Rat trait & you are in business.
What most programmers will do is focus on the nouns. So they will first define a class Cat {} with two methods catch() and eat(), then a class Bird {}, then wonder about whether there must be some class Animal {} which Cat & Bird must inherit from, except that birds aren't really animals, so...finally they'll create a cat object and a bird object and call cat.catch(bird) and then cat.eat(bird). When the program runs, there'll be many cats & many more birds & all these little objects will unnecessarily bring things to a crawl.
This has nothing to do with CoffeeScript the language, which ofcourse supports FP as much as it does OO. Its just that in practice people latch on to the OO aspects of CoffeeScript because that's just how most people process problems.
Besides that, I am currently reading Scala in Depth (Suereth) and re-reading Refactoring (Fowler).