Scala 2013: A Pragmatic Guide to Scala Adoption in Your Java Organization
Is Scala too complicated for widespread adoption in Java teams, or is it that Devs who tinker around with things they dont fully understand make Scala seem overly complex?
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
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
Stay close to the shallow end of the “Scala
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
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
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