I’ve been interested in learning more languages for quite some time, and recently I decided that it’s about time to add another one. Most recently I added Ruby to the mix, and I feel like I know it just well enough to get by. Modules are still a mystical and annoyingly complex box, but for my needs (throwing together scripts, and doing automation testing) I know it well enough for now. This time around I’ve chosen Scala. Scala is a derivation of Java. Or an evolution of it, I’m not really sure which term applies better.
Setup
Setting up an environment to start playing is easy. In OS X, you should already have Java 6 without needing to do anything special. If you want to have a newer version of Java, I’m sure it won’t hurt, but for just learning the basics of Scala, I’m sure Java 6 will be fine.
- Download the latest version of Scala here.
- Unzip it somewhere. I put it in ~/sd/scala-2.11.2/
- Make some modifications to your
~/.bash_profile
123#Scalaexport SCALA_HOME=~/sd/scala-2.11.2/export PATH=$PATH:$SCALA_HOME/bin
Now we can get into the Scala REPL just by opening a terminal and typing scala
You’ll also need to setup sbt, which is the scala build tool. I personally use IntelliJ, but even with IntelliJ’s scala/sbt support, it took me a long time to get up and running compared to just installing sbt. The easiest way is to use Homebrew or Macports
|
1 2 3 4 5 |
# Homebrew brew install sbt # Macports port install sbt |
Variables and Constants
In Scala, mutable and immutable variables are declared differently.
|
1 2 3 4 5 6 |
//use 'val' to create an immutable variable (like a constant) val helloWorldImmutable : String = "Hello World" //use 'var' to create mutable variables var helloWorldMutable: String = "Hello" helloWorldMutable += " World" |
We can also declare variables using type inference.
|
1 2 3 4 5 |
//use type inference to shorten code val foo = "bar" //without type inference val foo2: String = "bar" |
You’ll also notice that I haven’t used a single ;. This is because, as is the growing norm, a ; is optional. You only have to use one if you want to put multiple statements on the same line.
Methods
Method definitions look to me like a mashup of Swift and Ruby. A method definition uses the following structure
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
//def methodName(param1 : type) : <return type> = code //we can do this on multiple lines def boolToInt(value : Boolean) : Int = { if(value) { 1 } else { 0 } } //or we can do this on one line def boolToInt(value : Boolean) : Int = if(value) 1 else 0 |
We also don’t need to explicitly put the return type of a method. We can once again use type inference. But there is a catch. Sometimes, using type inference can cause some programming mistakes, so my personal recommendation. Use type inference for variables and constants, but never ever, ever use it for the return value of a declared, named method.
|
1 2 3 4 5 |
//Using type inference, this will return an Int def boolToInt(value : Boolean) = if(value) 1 else 0 //Using type inference, this will return an Any because it can return 1 (Int) or "0" (String) def boolToInt(value : Boolean) = if(value) 1 else "0" |
In more technical terms, methods are declared with the following syntax
- The word ‘def’
- The name of the method
- parameters separated by a ‘,’ of the following form
- variable name : variable type
- Optional : with return type
- =
- Implementation of the method
- This could be an inline method, or we can use { }
It is also important to note that there is no need for an explicit return in your methods. If you don’t have an explicit return, then the last line evaluated in your method will be the return value. You can still use explicit returns, but it seems that to have an explicit return, you must have an explicit return type. Also, return can cause some odd behavior from within functions inside of methods. I’m not entirely sure I understand the implications of return at this time.