ABC's of Scala

ABC. Assume nothing. Believe nobody. Check everything.

- John Cockram - British Crime Scene Manager

I would love to say that I spent the last 2 months learning Scala . Instead, I have to say that it has been 2 months of wrestling with

• Academic documentation unrelated to day-to-day development or learning.
• Documentation that is unconnected to the current implementation and not marked with what version it is connected to.
• Tools that are a decent alpha quality (and therefore better than the majority of the documentation).
• A language that is not just a moving target, but a dodging, weaving, actively evading target
• A large series of half completed build tools, testing tools, libraries and frameworks all driven by the NIH principle, many of whom reimplement the same concepts over and over and over and over.
• A separate ecosystem of artifact repositories

Some things I have discovered along the way that may help others 

(WARNING: much of this information will be outdated in the next 5 minutes)

The best book for learning Scala

So far the best book I've found for learning Scala is O'Reilly and Associates' Programming Scala by Wampler and Payne. Simple explanations and definitions of the concepts combined with code examples that are related to the concepts being described.

General assumptions to save you time

Some of these may sound tongue-in-cheek or harsh.. They are intended to be neither. I consider these rules to be just a straightforward and logical as saying "don't stick your hand into dark crevices" in areas where there are black widow spiders.

1. Assume that the documentation is outdated. , You should not proceed until you have proven that the documentation is connected to the version of the language or the library that you are using. 
2. Assumed that the source for examples or tutorials does not build until you have confirmed that it can be built in a standalone manner unrelated to the project you're working on.
3. Assume that the libraries in the Maven central repositories is out of date.
4. Assume that the transitive dependencies will NOT be filled out. 
• If the library you are using needs another library, you will probably need to specify it in the build.sbt file and you should not trust the documentation to tell you what version of that library is needed by the version of the code you are using. Instead, you should look at the dependencies listed in the source code of the library that you are using.
• For example, even though the Spray libraries say that they are built on top of Akka 2.0 you will probably not have those libraries automatically pulled in. You will have to go to the appropriate repository that they got pulled from and walks through their dependency information OR change logs, so that you can figure out what version of these other libraries are needed.
5. Assume that whatever library you have pulled down is a partially implemented experiment. Until you have proven that others are using it in projects that are actually ongoingly developed by someone other than the author of the original library you pulled down, you should assume that the entire library is a false trail designed to deceive. 
• So my recommendation is to test it always in isolation before

Specific assumptions to save you time

Scala-IDE

You can use the Scala IDE with either Indigo of Juno with the following caveats. 

I would recommend using only the SBT based builder with ONLY a build.sbt file. Do not use IVYDE in combination with the Scala IDE or ivy.xml files. , I would not recommend mixed Java and Scala
projects unless you an extreme masochist.

1. Assume that the Scala IDE error messages are unrelated to the code until 
• You have closed and then reopened the source file
• Refreshed the project
• Executed a "Build Project" command.
2. Assume that the Scala-IDE error messages are going to make no sense.
• If you are not able to find the error message in Google, you are better off rewriting the section of code than attempting to figure out what the error is.
3. Make sure that the library versions that you are pulling down match the version of Scala listed in the build.sbt EXCEPT that even though the latest version of Scala IDE pulls down and uses 2.9.3 of Scala the version of scala used by SBT is 2.9.2. So you can have the following build.SBT file:

name := "canon"

version := "1.0"

scalaVersion := "2.9.2"


But not


name := "canon"

version := "1.0"

scalaVersion := "2.9.3"

SBT

1. Do not use any of the SBT tutorials or documentation EXCEPT those found on the GitHub site for xsbt. All others are out of date and incorrect. 
• Double check that the version of the XSBT documentation you are looking at is tagged for the same release that you are using. 
2. When attempting to find libraries look first at the Typesafe and Spray repositories before attempting to use any of the maven central repositories. They are more up to date in general.

Why am I still at it?

The functional programming paradigm and the Scala language offer a huge opportunity in productivity.

Unfortunately, it is necessary to wade through a phenomenal amount of un-workability in order to get there.

Still experimenting like crazy