The language Dilemma!

scala

When my cofounders asked me to chip in a new venture, I was more disappointed than excited to know they are developing the platform on Java/Spring based framework. While there is certainly nothing wrong with it, it reeks of years of following whimsical enterprise standards and bloated code that can kill your libido faster than you can say Java. I knew as a startup in nascent stages we had to be agile enough that even major changes didn’t hinder us with a rigid architecture and configuration changes. The question now was what to pick up as our primary dev language. While answering this question, I listed out all of the parameters which were important to us:

  1. Our new language had to be based on JVM considering its widespread reach and years of experience all of our cofounders had developing in Java and related frameworks (please no .Net or any of the esoteric new languages that also compiled on a PDP-X).
  2. The language had to have enough functional features to allow a smooth transition after years of OO hoopla being bombarded on us by Java but not so high on the order that we felt lost looking at the code.
  3. Finally, it should allow each person to transition at their own pace, allowing them to use Java where necessary.

This narrowed down our subset for languages to limited few languages and we quickly settled down on Scala as our language of choice. The major factors which influenced our choice for this:

  1. Scala allows one to easily blend OO and functional programming.
  2. The simplicity with which you can iterate a list performing actions on it and then returning an output is amazing; consider the following snippet from Programming Scala(it takes args converting them to uppercase and printing them out): 
    def main(args : Array[String]) = {
    args.map(_toUpperCase()).foreach(printf("%s",_))
    } 
  3. We were particular bought over by Scala traits to the age old problem of single inheritance in Java.
  4. Scala’s adoption by industry.
  5. The list of Scala frameworks in existence is a testimony to its young and vibrant community of developers (most of these have active mailing lists).
  6. Scala allows easy integration with Java API’s, it’s as simple as just calling the Java API as one would normally call them from Java source. This was really helpful for us since some of the API’s that we used weren’t yet available in Scala.

The closest competitor to Scala was Groovy which promised similar features. However it lost out on following counts:

  1. Groovy is designed by JCP while Scala is more or less the brain child of Martin Odesky. While I have nothing against the JCP (discounting the fact that much of the bloat we have is given by them), I believe things designed by a single person have a much better design philosophy which ultimately gets reflected in its minute details.
  2. Lack of web frameworks (or any generic frameworks) written in Groovy. Scala on the other hand is overflowing with them.
  3. Scala XML support is much better (in my opinion) than that of Groovy. Plus there are additional XML libs in Scala.
  4. Scala has a considerably better benchmarking score than Groovy.
  5. Scala has twice as many questions and followers compared to Groovy on StackOverflow.

It took us approximately four weeks reading and practicing Scala examples (mostly over weekends) to bring us to the point where we were ready to write actual code. It took us about a week to rewrite our Java/Spring app completely in Scala (and related frameworks). We’ve had many changes and enhancements to our product and Scala has been great language and tool for rapidly prototyping and development of new features. I’m sure that any code we write now is “functional” from our current understanding of the language and its features; we’ll have better perspective as we tread along!

One thought on “The language Dilemma!

  1. Nice post. I too have found it interesting to learn Scala and to see how succinct it is compared to Java.

    My only problem with it is that I wrote a program in it and then came back to it in a few months to find it almost illegible. Even though you can combine five list transformations into one line, I would highly recommend against it. It’s going to make debugging harder than necessary, too, if you ever need to observe the state of the list as its halfway through its transformation.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>