If you’ve ever read my blog, you’re well aware this former Java junkie is smitten with Scala. It’s a blast to work with and such a breath of fresh air after a decade of preferring Java. However, even this Kool-Aid drinking fanboi knows it’s not perfect. To think any single technology is unblemished and appropriate for all situations is flat wrong. After a recent twitter conversation regarding the adoption of Scala, I began to think of plenty of reasons I wouldn’t recommend Scala. Hence I think it’s time I balance my tech crush with Scala with reasons you shouldn’t use Scala if you are currently considering it, particularly for a team project. Scala may not be right for you if…
You expect to quickly master the language
Let’s be honest here. Scala has a huge learning curve for many folks, as it is attracting droves of developers unfamiliar with the functional programming paradigm and its powerful static typing features. If you’re in this camp, you won’t master this language in short order. I’ve been infatuated with it since I took the Functional Programming Principles course in late 2012. While I’m competent enough to lead a project built with Scala, I have a long ways to go before achieving mastery. I’m just now exploring the type system for that matter. It may be true that new comers can become productive in a few weeks, the paradigm shifts are challenging and will demand you spend much time unlearning bad habits in route to a gradual mastery of the language. If challenges are not your cup if tea, look elsewhere.
Your team lacks a leader who loves Scala
Because of the aforementioned learning curve, adoption among a unanimously disinterested group of developers will be met with frustration, eroding morale, and dissension. Without at least one vocal and patient leader who is willing to teach through the challenges faced by the team, it is probable you could end up with an insurmountable upheaval. I have attempted some level of Scala adoption on two separate teams, and I can attest to the swift judgement and dissatisfaction among developers not interested in learning a new technology regardless of its merits. The first attempt failed for several reasons which brings me to my next caveat.
Your team culture doesn’t love improvement
If your team has been contently doing its thing for a long time, expect a crippling resistance to Scala. This is particularly the case if the team has not adopted… no… embraced agility. Without such a mentality and value system, I scarcely believe the team will survive such a change. The team simply isn’t equipped to navigate the waters of change and will likely be shipwrecked before exiting the harbor. On the other hand, if it is a team ingrained with a culture of finding ways to get better and you are able to demonstrate that Scala offers a potentially greater value to your team, then you may have a winner. I think it needs to be introduced to a team who routinely makes investments into their craft, as it will require changes to the environment, new IDE’s (I hate to feel strongly about non-open-source software, but IntelliJ IDEA13 boasts a fantastic Scala plugin makes the eclipse-based Scala IDE seem unusable [EDIT: IntelliJ Community Edition is also available for free per Apache 2.0. Thanks Jon-Anders!]), just for starters.
You have more man power than brain power
Still along those same lines, Scala may not be worth the investment if you have more man power than brain power. Let’s face it, not all developers were created equally. If your organization has not focused greatly on finding and developing the best talent in the software industry, and instead has amassed a large number of developers who are less than passionate about their craft; then Scala will not likely uptake well. Martin Odersky is on record stating that Typesafe is has a goal of mak[ing] Scala the language of choice for smart kids. Don’t bother to read between the lines and find ageism in that statement. The point is that Scala is targeted towards upper-tier developers who are motivated by the intellectual challenges that can be posed by a paradigm-shifting language like Scala.
Your organization is risk adverse
You don’t love math as much as code
Now just one moment before you flee the scene! I don’t mean continuous mathematics such as trigonometry, calculus, differential equations, Fourier analysis, real analysis, complex analysis, blah, blah, blah. I’m talking about the discrete mathematics you likely experienced as an undergrad while earning your software degree. You know, the good stuff like set theory, functions (a.k.a. “mappings”), group theory, Boolean algebra, graph theory etc. Functional programming has deep roots in the these fundamental mathematical theories. Not only do you find yourself working with collections and “mapping” over them very early in your foray into functional programming, these languages tend to embrace terseness in their respective idioms and expressions. Scala in particular relaxes the restrictions on names allowing special characters throughout the code, giving a much more mathematical feel (or “cryptic” to use the words of those who aren’t into math).
You love Haskell
Let’s take a look at the opposite extreme and consider Scala for those who love Haskell. If that is you, you will hate Scala. Just ask the likes of Tony Morris or Brian McKenna. While Haskell has been an instrumental influence on the design of Scala, category theory aficionados have a distaste for the unsoundness of Scala in that arena. For simpleton Java developers like me, the type system is so overwhelmingly more powerful than our understanding of the utility of a type system, that it seems more than sufficient. While the scalaz can give the illusion of a Haskell-lite on the JVM, it will likely leave a bitter aftertaste in your mouth. Speaking of the JVM…
You don’t need the JVM
Seriously, if you don’t need the JVM, don’t reach out for a language which hijacks it. The JVM is a brilliant and solid piece of software, but if you’re shop isn’t already well-versed in the Java ecosystem, I would be hard-pressed to find arguments in favor of its adoption. Simply stated, the JVM was not designed for functional programming languages. Although the developers of Scala, Clojure, etc have been incredibly clever in their utilization of the JVM, it fundamentally lacks features such as proper tail calls needed for a solid functional programming runtime. On the other hand, if your team has a heavy investment in Java technologies, you will be leveraging one of Scala’s greatest strengths.
You quit reading this blog post already
If you’ve already stopped reading, then I’ve either identified show-stopping issues for you, or your interest level in Scala wasn’t able to sustain you through this post, nor will it sustain you through the difficulties of its learning curve.
Wrapping up now, I hope you’ve caught on to a common theme here. With the exception of my last point regarding the JVM, none of my caveats are technical. They all involve considerations of the people you have because no matter what technologies you are considering for a team, it is a people decision, not a technology decision. It has more to do with the culture you hope to establish than any technical considerations.
Those are the reasons that come to my mind anyway. I’m sure there is a plethora of others. Got any yourself? Please drop a line below in the comments.