Scala

One thing that I like working for my company is that it tries to evaluate new technologies from time to time. About a year ago I got a task to learn Scala by writing a small internally used tool in it and share my impressions. The main question I was supposed to answer was: “Should we use Scala (instead of Java) to implement the next iteration of one of our products?”.  I had a feeling that my boss would have liked me to answer enthusiastically “yes!” to that question. And I really liked the language. However, my answer was “probably not”.

What I liked about Scala

I don’t want to write about all the advantages of Scala. After a small project I don’t think I have anything meaningful to add to the things other people have written. It’s a functional language. It feels like Haskell – if it compiles, it most likely runs OK.  I was amazed by the type system – supporting both  Java classes and functional programming in a Haskell-like statically typed language and not running into some fundamental show-stoppers is quite incredible. I used IntelliJ IDE to write the code and after overcoming the initial Maven integration problems it worked fine. It’s the first time I worked with Java style IDE and I liked all the help it gives. The compilation times were long, but IDE checks syntax on the fly, so there is no need to build something just to see if it builds.

What I didn’t like about Scala

Nothing specifically about Scala. It was my first encounter with programming in the Java world. I got a general sense of bloat and fragility. More than half of the time I was struggling with configurations and set ups – IntelliJ, Maven, Jenkins, Artifactory and interactions between all that. Some of the problems could have been the result of my lack of experience, some was due to Scala being somewhat nonstandard for those tools, so it was more difficult to find solutions on the web. Another problem I had was a different idea on the tradeoff between writing your own code and using an external library to do things.

So why “probably not”?

In my evaluation I looked both at success and failure stories (which not surprisingly were more difficult to find). I think evaluating possibility of switching the development to Scala management may make two mistakes. One is thinking that this is a technical problem – they try to identify problem domains where “Scala is best” and since what the company makes fits the advertised Scala strengths (large scale, concurrent, Java legacy code etc) they hope that Scala will bring gains in productivity. I think the main criterion for taking the risk of switching to Scala should not be the kind of software you write but the kind of developers team you have. The second mistake is made by people who understand that this is a people problem, but think that since they have very talented and experienced Java developers (or are planning to hire such), they should be OK. Here is the heart of the problem:

Scala is not a better Java, it’s an ML for JVM

If you don’t know what I mean here, that’s probably what I mean.

The problem is a bit wider than Java vs. Scala. It’s more like imperative vs. functional programming. I believe OO and imperative programming is fundamentally closer to the natural way human brains are wired. To feel comfortable with functional programming one has to either have a (rare) natural talent for this particular abstraction or have a brain warped by years of training (in mathematics for example like myself). This is one of those barriers that are invisible for people who are on the other side of them. This is the main reason why functional programming languages are so dominated by imperative ones in all popularity statistics.

An alternative view is that the only reason most people find it easier to formulate algorithms in the imperative way is that this is what they first encountered in their education. If their first programming language was functional, then we would see the opposite result. I admit that this imprinting effect may exist to some degree, but I don’t think it is important. I would have to see a well designed experiment to change my opinion.

I have seen opinions that the difficulty of switching to the functional style is something that happens to “average” programmers. For good, smart and eager to learn ones functional programming is natural. I think this is an illusion. In fact, very experienced and productive Java programmers have even more reasons to resist the switch, especially if it is unilaterally imposed by the management.

So what kind of a team will benefit from switching to Scala and when this will most likely lead to failure? There is one good proxy criterion: if the team wants Scala, they will like it and there is a good chance for success. If the switch is something that they have to do because of a management decision, there is a high probability of failure.

So, may recommendation was “Scala? Probably not, at least not now”. I have a little bit of hope that it will be ignored and I will get to have fun with Scala some day again.

About these ads

2 Responses to “Scala”

  1. Nicolas Says:

    You should look at fsharp. It stays in the OO and does a better job at it if you want to stay there. But it also provides advanced functional kick where you need it. It runs on Windows / Linux / Mac with either dotnet or mono.

  2. Scala Appreciater, Java too, Scala being built on it Says:

    The big learning curve with Scala comes from learning how to use the power that’s specific to Scala. Learning how to use Java in Scala requires very little learning.

    The Scala build tools, sbt being the standard one, where I use Gradle, use a default directory structure which includes `src/main/scala` and `src/main/java. Integrating Java in Scala is pretty effortless.

    I disagree with your heading, “Scala is not a better Java, it’s an ML for JVM”. If it was my heading, I might say, “Scala is an extension of Java, one part of it being a ML for the JVM, but with better syntax than ML, though not with syntax nearly as good as Haskell.”

    A large part of the power of Scala is not specific to functional programming. You don’t have to do any functional programming in Scala. Said another way, you can transition into functional programming as you find time.

    What that means is that you can set up a project to be a Scala project, and then choose to use the power of Scala in a Scala source file, or stick with programming in Java in a Java source file, or program in an imperative style using Java libraries in a Scala file, with syntax that is Java-like, but more streamlined.

    Part of the genius of Scala is that it allows you to use Java-like syntax. On the other hand, that part of the genius is also its shortcoming, but only for people who have experienced the streamlined syntax of Haskell. But then, the number of Java users dwarf the number of Haskell users, so staying with Java-like syntax is most likely a big part of what got Scala its acceptance.

    I wanted to go with Haskell because of its mathematical syntax, but with Scala, Scala/Java/JVM becomes the mother of all computing platforms. The object oriented part of it, along with Java’s huge standard library, along with the fact that huge numbers of people use Java, makes it the right choice over Haskell, for me.

    Since I’m not an expert Java programmer, I’m making an intentional effort not to use examples in books where the author teaches how to do things in Scala, but not really in Scala, but using the standard Java methods, in Scala.

    Anyway, the only reason for you to not set up a project as a Scala project would be because the little bit of learning to know how to do Java in a Scala project would still be too disruptive.

    Like I said, a big part of the power has nothing to do with functional programming, at least on the surface.. Part of the power is iterators.

    var docDependenciesList : List[String] = List()
    for(relPathFile <- “_FILE_”.r findAllIn fileAsString)
      docDependenciesList = relPathFile +: docDependenciesList
    for(relPathFile <- docDependenciesList) println(relPathFile)

    With only a basic understanding of both programming and functional programming, I’m slowly porting over a script I have in another scripting language, into Scala. I could do it in Java-style in Scala, but if I did that, I wouldn’t be learning the power of Scala, and there’s a ton more syntax clutter in Java. Getting a more streamlined syntax alone is worth using Scala over Java.

    I can’t help but point out one of the many simple feature that’s great. In Scala, you don’t have to manually do all the overhead to define your constructors for a class. It’s all done with typical programming syntax, `class Foo(s : String) {…}`. You probably knew that.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: