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 flexibility 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 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”.
What will you find in the report?
This report gives you what you need to know about experimenting with Scala programming in your Java team – a 15-page exclusive interview with Martin Odersky, another 15 pages of analysis, code, tips and tricks, including commentary from Josh Suereth, Scala expert and author.
Exclusive Q/A and advice on getting started with Scala by the language’s founder:
“Scala is a wide tent because it lets you program in what is essentially Java style without semicolons and it lets you do the most advanced parts of functional programming if you so desire. The first thing to know is that being more abstract and more functional is often better but not always. There is no better or worse here. For some problems and themes, a Java-like style is actually very appropriate; for other problem areas, you want to be more abstract. The second observation is that if you start with Scala be prepared that you will make a journey.” – Martin Odersky
Technical analysis of Scala’s pros and cons:
There are some things in the Scala ecosystem that will seem like a foreign language to someone coming from Java. They may be fun to mess with and may actually be useful, but if you are trying to adopt Scala in a team of Java programmers, these things might work against you; such as finding yourself inadvertently in the deep end. We think the following parts of the Scala ecosystem are better avoided when just starting out:
- SBT – Simple Build Tool
- Category theory
- Libraries that overuse “operator overloading”
- Collections Library Source Code
- The Cake Pattern
- The Kingdom of Verbs
- Too Functional or Too Type Safe Code
But what is so great about Scala in the first place, that Java developers should consider using it? A detailed account would take more words than we’ve space for here, but here’s a brief overview of what the language features enable:
- More intentional code – get rid of boilerplate
- DRYer code – thanks to type inference
- More abstractions – less copy & paste
- More concise code – 2-3 times less lines of code than equivalent Java
- Immutability is easier – you might be surprised how seldom “variables” need to vary
- Slightly more functional code – but still familiar
- Functional abstractions over collections – loops become one-liners with lambdas
- New ways to compose things
- Pattern matching – forget if-else chains
- Java interoperability – easily interact with existing Java code
- Good performance – as fast as Java, with some caveats
So, is Scala really too complex or are non-experts making hasty judgement calls? The goal of Scala 2013: A Pragmatic Guide to Scala Adoption in Your Java Organization is to help you understand whether it is worth it to consider bringing Scala into your Java organization in 2013 – to understand that Scala is as complex as you want it to be, and which end of the Scala “swimming pool” to jump into at first – and decide whether you will sink of swim from there.