How to bring Scala to Enterprise IT

Yesterday was the first day of a conference for Java developers in Kiev, Ukraine. I delivered two presentations and attended three delivered by very good speakers. Reza Rahman from Oracle opened the conference with an overview of Java EE 7. This is a Ukrainian version of Reza:

SONY DSC

Then I attended a presentation on functional programming in Scala by Jacek Laskowski from IBM. I thought I had a pretty good understanding of what functional programming is about from JavaScript. I know what closures and callbacks are. But this presentation demonstrated how to take the concept of functional programming and dynamic typing to the extremes. Half of the time the audience was guessing what a particular language expression could mean, while the second half Scala compiler was guessing what should be the data type of a certain variable or expression. Here’s one of the not for the faint of heart examples:

(Int => Int) => Int

This presentation has confirmed my feeling that I can easily retire without even looking in that direction. Not because I’m not getting excited by new toys for programmers. I’ll definitely read a book on Scala to be a better programmer in other languages. But it’s impractical in today’s enterprise development where people prefer Hibernate to SQL and Spring to Java. This is a world of framework coders. (Int => Int) => Int? Yeah, right.

The presentation by Dr. Venkat Subramaniam was engaging and well done as expected. He was comparing different languages that run on JVM. The audience had to fill out a spreadsheet assigning weights to different features of the languages Java, Java 8, Scala, and Groovy. For example, if having a dynamic typing or meta-programming support is very important for your project – give them a 100. If you don’t care about those – give them a 0. If you somewhat care – give any number in between. On the right hand side of the spreadsheet the numbers would add up showing that functional languages are in the lead.

But this spreadsheet was missing two rows: talent pool and community support. If these two rows were present, Java would have left other contenders in the dust. Imagine a hypothetical situation, when I’m running a typical enterprise project that includes seven Java developers one of them being Venkat (this makes a project not so typical, ain’t it?). Venkat convinces me that one of the newly developed modules has to be done in Scala, which will save us on development time, the code will be concise, and we’d just need to add one more Scala jar to the hundred of Spring/Hibernate jars that we already have anyway.

Let’s say I agreed to this, Venkat did a good job, the module was written fast and worked as expected. Do you know where am I leading? Exactly! For some reason Venkat decided to leave our firm. Now what? Who’s going to maintain this code? The talent pool of Scala developers is miniature. The community is small. No good.

But this presentation by Venkat made me thinking of how to make efficient and JVM-based languages practical in the enterprise setup. Here’s how to do it. If you have a team of several Java developers and want to introduce Scala, Groovy or any other exotic language, do not hire a person who knows this language. Hire an instructor to teach the entire team how to program in this languages and let one of the developers use it in your project. This way you’re covered. The chances that all seven developers quit on you are slim.

I believe this can become my New Year’s resolution: I’ll master Groovy myself, then will teach our entire team and find the right piece of the software to be written in Groovy. What about Scala? This may become my resolution for 2015, I guess.

This is my takeaway from the JEEConf. This blog can serve as an example of why attending technical conferences is a must for any software developer. I’m looking forward to my next conference-vacation in August.