Category Archives: scala

why dynamic languages are not cool

Some people love dynamic languages. I don’t. This last week, I found one more reason for it. I might be a bit biased because I love Scala, but lets go for it.

A project I started maintaining a few weeks ago is written in python. I don’t know much python yet, so there is this fact in and by itself. And I must say I’m liking the language. Now, the fact that it is dynamic has already bitten me at least twice.

In one of those, I was trying to understand why a test I just wrote was not working. It was as if one line was being simply ignored… Well, looks like I discovered by accident that I can call methods that doesn’t exist, at least on some objects or classes. I had a misspelled method name. As soon as that was fixed, everything worked fine. Half an hour lost with a problem that the compiler / interpreter should really warn me about.

The other case was a property in an object that simply disappeared. At a certain point in a function, it was there. A few lines later, in the SAME function, it was not anymore. At least this time it was simple to find the problem: a reassignment was being made, which was changing the type of the object.

Again: changing the type of the object. With an assignment. Yes, from a static language lover, this just feels absurd. There is no way this was going to happen in a statically typed language.

Lets end this rant on a positive note. I am liking python. Still, I would like it much more if it was statically typed.

By the way, we are going to have a new scaladores meeting in Sao Paulo on Feb. 23th. If you are in the region by then, please stop by. More information (portuguese) here.


Matching a combination of class and trait in Scala

While doing some development with Scala I discovered that it is possible to match combinations of a class and traits. It might seem obvious if you already know it, but I didn’t.

What happened is that I needed something like matching that kind of combination… and this speaks to something about Scala that I love: it becomes intuitive after a while. So how did I find that such matching is possible? I simply tried… =)

This is what this feature looks like:

msg match {
  case x: X with Z => println("matching combination!")
}

In this case, X would be a class, and Z a trait. The case x will be triggered only if msg is an instance of class X and mixes in trait Z. With this, we make sure to have access to all members both from the class and from the trait, while being really type safe about the matching. No unsupported combinations will pass through, and no need for castings, like would be necessary in Java.

Lets try a dummy example. Imagine we have a Superman class, and two traits: BlueCape and RedCape, like the following code:

class Superman(val realname: String)
trait BlueCape
trait RedCape

Now, we want to match on a Superman instance, but we want to know if it is fake or not. Finally, we also want to print the guy’s name, which means we need access to the realname field. This is how you could do that:

def whichSuperman(superman: AnyRef) = superman match {
  case s: Superman with RedCape => println("real superman: " + s.realname)
  case f: Superman with BlueCape => println("fake superman: " + f.realname)
}

Flexible and type safe! And if the traits had any field, we would be able to access them as well. Quick sample test code:

val mys = new Superman("clark") with RedCape
val myf = new Superman("clurk") with BlueCape

whichSuperman(mys)
whichSuperman(myf)

The part that matches the class is not very useful in this example, since this could be defined in the function parameter, but it was in my local scenario, where we are using actors and the messages can be AnyRef.

If you want to know a bit more about pattern matching, I wrote about it a while ago here. I also described how to match a range of numbers here.


scaladores first meeting

Right to the point: we are starting a Scala user group down  here in São Paulo, called Scaladores. The idea is to for people interested in the Scala language to meet in person and talk about it. If you are in the region, please drop by – the first meeting happens this thurday, at 7pm. The portuguese page with more information can be found here.

I’ll come back after the meeting for a ‘report’ of how it went =)

In time: I should write more posts about scala soon, just need to get some stuff in place before that.


Acidental scala upgrade with sbaz

And then I was playing around with the scala tools that come in the installation’s bin folder. There is something there called sbaz, and this name sounds so different that I just HAD to play with it to find out what it does.

Lets first explain what I discovered later: what sbaz does. It is some kind of scala package manager for your local scala installation. If you issue a sbaz available, it will list all packages it is able to install for you, for example. Also, and this was the somewhat tricky part for me, it is able to upgrade all current packages to their latest versions, including the main scala stuff, like the scala-library.

This is all great.. as long as you don’t run sbaz upgrade by mistake. This happened some weeks ago to me… And I was lucky enough to not have any major problem. I was running scala 2.8.0 at the time, and 2.9.0 was already out. Result: I upgraded to scala 2.9.0 before I intended to… and one day before a speech I gave at a conference, where I presented plenty of scala code examples.

In the end all went well, but I had to update some sample code, and to upgrade the Netbeans scala plugin to the version that supports 2.9.0. The other option would be to erase the installation folder and install scala from scratch again, but I chose to use this “event” to upgrade to 2.9.0 for real =)

Bottom line: learn that scala has a very nice package manager tool called sbaz, but use it with care ;)


Scala’s Parallel Collections are useful even in the most simple cases

One of the main features that Scala version 2.9.x brought was Parallel Collections. If you think about it quickly, you might consider using such a feature only in complex, process intensive scenarios.

Although those are certainly the main places where you would consider using parallel collections, there are more simpler ways you can leverage them. The code to use this feature is so simple that it’s easy to come up with reasons to use it everywhere:

myCol.par foreach(println)

Now how could that be easier??

So where did I use that for real, you might ask. The current company I work on stores files in Amazon S3. Before that, those files where stored in the local disk. So, when we migrated to S3, I wrote a script, in Scala, to upload all the files… thousands of them. My first solution looked something like this:

listOfFiles foreach(file => sendToS3(file))

And then suddenly it occurred me that it’s ridiculously simple to parallelize the upload of the files:

listOfFiles.par foreach(file => sendToS3(file))

Result: half the time for uploading the files, having to do almost nothing! Pretty neat, ain’t it?


Scala Problem Number Six

From the Scala 99 Problems, lets face the problem number six:

P06 (*) Find out whether a list is a palindrome.
Example:

scala> isPalindrome(List(1, 2, 3, 2, 1))
res0: Boolean = true

The first thing I had to do was to find out the meaning of palindrome. From the example, it’s easy to guess, but I prefer to be sure. So, from dictionary.com:

1. a word, line, verse, number, sentence, etc., reading the same backward as forward, as Madam, I’m Adam  or Poor Dan is in a droop.

Interesting, so this is valid not only for numbers =)

Now, to some coding! My first solution:

def isPalindrome(list: List[Any]): Boolean = list match {
  case Nil => true
  case head :: Nil => true
  case head :: rest if head == rest.last => isPalindrome(rest.dropRight(1))
  case _ => false
}

This first solution uses pattern matching to investigate the list recursively. It checks if the list is empty or if it contains only one element and returns true. Otherwise, it checks if the head of the list equals the last element. If so, the rest of the list (its middle part) is passed recursively to the function. This is one more case where we can see the great power of scala’s pattern matching in action.

Also, the solution will work with strings as well, so it matches the dictionary definition – just call toList on the string. Sample execution from the REPL:

scala> isPalindrome("oio".toList)
res11: Boolean = true

scala> isPalindrome("oioo".toList)
res12: Boolean = false

To be honest, I don’t feel too much creative when thinking about this problem, so the next solution is quite similar to the previous one, but without pattern matching:

def isPalindrome(list: List[Any]): Boolean = {
  if (list.isEmpty || list.size == 1) true
  else if (list.head == list.last) isPalindrome(list.slice(1, list.size-1))
  else false
}

Now lets take a look at the original solution and… I’m stunned by its simplicity. While I went all fancy at things like pattern matching, the original solution goes like this:

def isPalindrome[A](ls: List[A]): Boolean = ls == ls.reverse

Yeah, I should have thought of that…


The Anagram Puzzle in Scala

A few weeks ago, we had a coding dojo in Adaptworks. There, we decided to use Scala as the coding language, and the problem to be solved was the Anagram puzzle. Unfortunately we didn’t manage to solve the problem during the coding session, but I’m sure everyone learned a bit more about Scala, which is always the main goal =)

Now, of course I wanted to have this puzzle solved. So I finally used some spare time and coded a solution. My solution is not the best possible one by any means, but it works and was really fun to work on.

Before showing the solution, a brief explanation of the problem, translated from the description in portuguese:

Write a program that generates all possible anagrams of a given string.

For instance, the possible anagrams of "biro" are:

biro bior brio broi boir bori
ibro ibor irbo irob iobr iorb
rbio rboi ribo riob roib robi
obir obri oibr oirb orbi orib

I’m still trying to find better and more readable solutions, but for now the current one is as follows:

class Anagram {
  def anagrams(word: String): Set[String] = anagram(word).toSet

  def anagram(word: String): List[String] = {
    if (word.length == 1) {
      List(word)

    } else {
      var anagrams = ListBuffer[String]()
      0 to word.length-1 foreach { i =>
        anagrams ++= (anagram(without(i, word)) map (word.charAt(i) + _))
      }

      anagrams.toList
    }
  }

  def without(index: Int, word: String): String = new StringBuilder(word).deleteCharAt(index).toString
}

In summary, what I tried to do was combining the ‘current’ char with all combinations of the rest of the input string. I hope this makes sense while reading the code. The code works – I have some unit tests that we generated during the coding dojo plus a couple more tests I added afterwards. Yet, I’m not happy with the anagram ListBuffer… I guess this could be solved in a more elegant way. Ideas?

An extra curiosity. While looking into the Scala Docs API to find possible ways to solve the puzzle, I discovered a very handy function that can be called on strings (and other kinds of collections as well): permutations. It basically solves this puzzle in a single method call…


Scala Problem Number Five

From the Scala 99 Problems, the problem number five goes like this:

P05 (*) Reverse a list.
Example:

scala> reverse(List(1, 1, 2, 3, 5, 8))
res0: List[Int] = List(8, 5, 3, 2, 1, 1)

Starting with the obvious solution, using the API:

val list = List(1, 2, 3, 4)
list.reverse

Yes, the List API has a reverse function. Pretty handy =)

How about being more creative now? Like this:

def myReverse[A](list: List[A]): List[A] = list match {
  case head :: tail => myReverse(tail) :+ head
  case Nil => Nil
}

With pattern matching and recursion, the solution is pretty simple. We basically decompose the list, and rebuild it in the opposite order. The code is simple, but it can take a while to understand if you are not used to recursion. The pattern matching part shows how nicely we can decompose Lists in scala =)

Lets try a different solution now:

def myReverse[A](list: List[A]): List[A] = {
  var reversedList = List[A]()
  list.foreach(item => reversedList = item +: reversedList)
  reversedList
}

Here we take a more ‘traditional’ approach – its closer to what we would do in Java, but still more compact and readable. First we create a buffer list, and add each element of the original list to the beginning of the buffer. Finally, we return the reversed list.

You can find the original solution to the problem here. As always, I learned something more after reading the original solution – I always write my solution before reading that. What I found is that it is also possible to solve the problem in a pure functional way, with foldLeft (copied from the original solution):

def reverseFunctional[A](ls: List[A]): List[A] =
    ls.foldLeft(List[A]()) { (r, h) => h :: r }

This solution is probably the most difficult to get at first, but the best after you get used to this kind of ‘extreme’ functional stuff. Nice =)


About nulls and System Properties in Scala

In Scala, it is usually a good idea to avoid nulls in your code. Instead of that, it is recommended that you use the Option class. This is how it works: if the value you are working with is null, it is represented by None, otherwise, it is represented by Some(value). Both None and Some are subclasses of Option.

This allows you to write code that is much more expressive than having ‘if != null‘ all over the place. Also, it is much less likely that you will forget to verify for nullity. One way of leveraging an Option value is through pattern matching:

val myValue: Option[String] = Some("Hello")
myValue match {
  case Some(x) => println("my value is " + x)
  case None => println("nonthing found")
}

The Option class also offers some collection-like functions that allow for great readability as well. From the Scaladoc:

val name: Option[String] = request.getParameter("name")
val upper = name map { _.trim } filter { _.length != 0 } map { _.toUpperCase }
println(upper.getOrElse(""))

Notice how the code execute transformations and ‘if-like’ filtering, in a very clean way. After that, they try to use the value with the getOrElse function, which allows you to pass a default value to be used if the result from the previous line was None. Finally, if you REALLY want to use an if statement, you can call the isDefined function, which returns true if the value is Some, false otherwise.

Now lets talk about system properties. Lets face it: dealing with System Properties in Java is boring. You have to get each property you are interested in and have to verify if it is null or empty. After all the talk above, you probably are starting to guess where I’m heading, right?

Well, it is better than that. Scala encapsulates the system properties in a way we can leverage all the Option stuff explained above. Those properties are encapsulated in a class named SystemProperties and can be accessed by the object ‘sys.props‘. Try typing it into a scala console session to see for yourself.

Since it is a map, you can use any map function you can use with other maps. Also, you can add and get properties from this object, and they will be reflected in the actual System Properties – which means that your Java code should be able to read the properties as well, even if through more traditional means (i.e. System.getProperty). Printing all system properties is as simple as:

sys.props.foreach(println)

And you clearly could do something more clever and useful with those properties.

There are two functions available in the SystemProperties class that I want to cover here: get and getOrElse. The first one returns a property with a given name, in an Option. With this, you can now handle your property with all the Option goodness we talked about above. The second function, getOrElse, is basically a direct way of calling the same function you could call in an Option. For example, lets say you read a database configuration from the system properties, and want to fall back to a default configuration if the property is not found:

val dbURL = sys.props.getOrElse("myapp.database.url", "jdbc:postgresql://localhost:5432/mydb")

A lot better than reading the property and verifying if it exists ‘by hand‘, right?


Migrating a java project to scala

Hi everybody!

This time I wanted to bring something different about scala – so I decided to migrate a java project to this language. The chosen one is an open source test framework for the Web Objects framework (sorry for the double f* word there) called WOUnit.

Web Objects is a web application framework that is quite old, and is developed by Apple. I’m not the right person to talk about this framework, so I’m not going further than that. The point is that this framework has some specificities that could make writing pure JUnit tests more troublesome than it should be, and this is where WOUnit comes in.

This project is reasonably small, so its a good choice for our small experiment. I’ll talk about what I did bellow, you can take a look in the project in the link above, and in the changes I made in my fork.

The current changes consisted of the following steps:

  • added the scala plugin and scala library dependency to the project’s pom.xml file – more about the maven scala plugin here;
  • renamed the EOAssert.java file to EOAssert.scala;
  • rewrote the contents of the file to use scala sintax

It was not complicated at all. You can find the current version of the file here. And what have we gained with this?

First, the code is now more readable. Which one is easier to read, this:

public static Matcher<EOEnterpriseObject> canBeDeleted() {
    return new CanBeDeletedMatcher<EOEnterpriseObject>();
}

or this:

def canBeDeleted(): Matcher[EOEnterpriseObject] =
  new CanBeDeletedMatcher[EOEnterpriseObject]

Nice, isn’t it? This comes to a point made by Martin Odersky (creator of Scala), where he said that the most important information in a function / method declaration is it’s name. Makes sense.

Second, you might have noticed that something seems to be missing in the scala version above. The java version has a static method, which doesn’t exist in scala. Actually, it isn’t even needed. Our EOAssert in scala is an object, which means scala handles it internally as a singleton. This feels a lot more correct from an object orientation point of view than having static things all over the place. Yet, from Java, you access EOAssert’s methods exactly as before – which means I didn’t have to change ANYTHING in the EOAssert class usages throughout the project, and it kept compiling and the tests passing.

Also, please notice how we are mixing java and scala code seamlessly here. Any doubts you could use scala as part of just about ANY java project without major headaches?

One thing I’m not sure about how it is working right now are the javadocs. In the migration, I kept then exactly how they were, and I’m not sure how the scaladoc would be generated for then. Since EOAssert class is intended as a public API, this is an issue that must be taken into account.

In summary, I didn’t do too much here – it was just a small experiment on migration a java project to scala. I hope you liked it and perhaps felt that scala is really worth considering serious usage. I’m not sure if I’ll continue this migration, but if I do, I’ll have more posts about it.

EDIT:

about the scaladocs point, this link might help a little bit: http://lampsvn.epfl.ch/trac/scala-old/wiki/Scaladoc/AuthorDocs


Follow

Get every new post delivered to your Inbox.