Franco Lombardo

In a very interesting interview, Martin Odersky said that Scala could be a little more difficult than Java for newcomers because in it you have not to write boilerplate code, but you have to think at your problem just from the first line of code. In some way, boilerplate code could be a kind of "warming up" for beginners. Writing some code, even if it's only syntactic noise, could give confidence to the programmer, generating a feeling of accomplishment.

But, is there a way to warm up without writing silly code? The best way of doing this is with unit testing. In TDD by example , Kent Beck describes "Starting tests": Start by testing a variant of an operation that doesn't do anything. Using these tests, not only you can start exploring your design, but you can also break the "white sheet syndrome".

As you can guess, I'm a fan of the Scala programming language. Nevertheless, unlike some Ruby evangelists, I can say that there is something in my favourite programming language that I don't like. Here are some examples.

Semicolon inference

The first one is about how Scala considers the end of statements.
Let's take a look at this code.

 
package bad   
 
object BadScala {   
 
  def subtractVersion1(a: Int, b: Int) = {
    a -
    b
  }   
 
  def subtractVersion2(a: Int, b: Int) = {
    a
    - b
  }   
 
  def main(args : Array[String]) : Unit = {
    println(subtractVersion1(10, 2))
    println(subtractVersion2(10, 2))
  }
}

The output of this program is

8
-2

Unlike Java, Scala does not require semicolons to close a statement. In Programming in Scala we can read

A line ending is treated as a semicolon unless one of the following conditions is true:
1. The line in question ends in a word that would not be legal as the end of a statement, such as a period or an infix operator.
2. The next line begins with a word that cannot start a statement.
3. The line ends while inside parentheses (...) or brackets [...], because these cannot contain multiple statements anyway.

So in method subtractVersion1 there is only one statements that spans two lines, giving a - b as return value. In subtractVersion2 the compiler infers a semicolon at the end of the first line, so the result value is -b.

The missing equal sign

Now let's see how forgetting an equal sign could be dangerous.

 
package hello   
 
object BadScala2 {   
 
  def myFavouriteLanguage1() = {
    "Scala"
  }   
 
  def myFavouriteLanguage2() {
    "Ruby"
  }   
 
  def main(args : Array[String]) : Unit = {
    println(myFavouriteLanguage1)
    println(myFavouriteLanguage2)
  }
}

This program gives as output:

Scala
()

(It seems that there is no way to make me say that Ruby is my favourite language )

The only difference between the above two methods myFavouriteLanguage1 and myFavouriteLanguage2 is a missing equal sign. In Scala if a method declaration does not have an equal sign before its body, the compiler infers that the result type will be Unit (something like void in Java). So, as also the return keyword is optional (and, in fact, it's never used in idiomatic Scala), the method will not give any result, or, we should say, a result which type is Unit, and it's rendered as ().

Is Scala a bad programming language?

So is Scala a bad programming language? In my humble opinion, Scala is a really powerful programming language, the best one I have learned so far. Anyway, in it there is a trade-off between power and safeness. We should know its weakness in order to use it effectively and enjoy its power.