Scala 2013: A Pragmatic Guide to Scala Adoption in Your Java Organization

Scala’s received some flak over recent months, with many developers suggesting its entry level is just too much. ZeroTurnaround’s Marketing Manager Oliver White tells us why it doesn’t need to be this way…

Is Scala too complicated for widespread adoption in Java teams, or is it that Devs who tinker around with things they don’t fully understand make Scala seem overly complex.

The technical review of Scala’s benefits and disadvantages presented in this report makes the JVM language a compelling choice for Java organizations to explore. Scala’s dynamism should be enough to let you write more concise and intentional code than in Java, but getting there is challenging. The deeper parts of the Scala “swimming pool” are sometimes fun to explore, but can be scary at first. Once comfortable with the simpler part, your Java team can consider taking advantage of advanced features and going further in a purely functional direction.

In this 30-page report on Scala from Rebel Labs, the research & content division of ZeroTurnaround, we interview Scala creator Martin Odersky, supply detailed technical analysis on the pros and cons of Scala programming and incorporate commentary by Josh Suereth, author of “Scala in Depth”.

A little background

Scala is a language created by Martin Odersky and his desire to combine object-oriented and functional programming on the Java Virtual Machine. Odersky’s previous work on Pizza, GJ, Java generics, the javac compiler and Funnel eventually led to the creation of Scala and its first release in 2003 at EFPL. Scala is purely object-oriented as every value is an object, and functional as every function is a value. The successful mix of OOP and FP paradigms has made the language relatively popular and a “better Java” for many. It’s also a good language for those looking for Haskell-like capabilities on the JVM.

Following the language’s rise in popularity, Typesafe was founded in 2011 by the creators of Scala and the Akka middleware, to provide easy to use packaging of both in the form of the Typesafe Stack, as well as better development tools and commercial support.

In the last few years there has been some criticism of Scala; it’s mostly been accused of being too complex. In this report, we opine that the perceived complexity of Scala actually arises more from the diversity of the ecosystem rather than the language itself. We then look at a simpler subset of Scala that is perhaps a good place to start for Java teams who are considering adopting it.

Stay close to the shallow end of the “Scala pool”?

Numerous blog posts during the past year or two have accused Scala of being too complex or highlighting other issues with Scala adoption. Some of the criticism is fair, but some of it could be targeting almost any JVM language out there. Scala seems to get more of the flak because it’s more popular and possibly pulling ahead of the others.

And also probably because Scala actually is rather complex, but only if you want it to be.

Think of Scala as a swimming pool — there is a deep end and a shallow end; it seems that many people who haven’t learned to swim yet jump straight into the deep end. Inevitably, after splashing about for a while are surprised to find that their legs don’t quite reach the floor, or that they sank to the bottom and are startled by not being able to breathe underwater.

Why does this happen? Maybe it is hard to distinguish the deep end from the shallow end — it’s not quite as simple as having a glance and getting a clear picture of how deep the pool is. Maybe the deep end seems more exciting at first, when you haven’t gotten a true taste of it yet.

Why talk about such a dichotomy in the first place? Because the Scala community is very diverse. It can cater both to newbies and expert type-safe library designers. Some Scala users come from an object-oriented programming background (e.g. Java), some come from a functional programming background (e.g. Haskell).

Scala blends together these programming styles, but still lets you code mostly in an “impure” imperative or mostly in a “pure” functional way. And that might be the main problem — the very different coding styles enabled by Scala means that a lot of code written by people from a school outside of one’s own might seem downright illegible.

Each Scala team needs to find a common style that they agree upon, or the result will be a mess. The Scala Style Guide might help with this.

Scala 2013: A Pragmatic Guide to Scala Adoption in Your Java Organization is mostly written for those coming from the Java (object-oriented / imperative) school. Some of the suggestions are very much a matter of taste, background and so on, so we’re not expecting everyone to agree with it. Sign up to read the full report.