prose :: and :: conz

Scala may not be right for you if…

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

Making a technology change is risky, no matter how well-calculated. An organization who believes failure is not an option (as badly as I want to attack that mentality, I will pass for now) will scapegoat the technology when failure occurs and possibly pin you and your Scala supporters to it. I’m hopeful that if you’re still reading this post, you already passed the agility litmus test offered earlier. In that case, you have a team and organization who embraces the inevitability of failure and is nimble enough to not only navigate the obstacles, but mature enough to not blame the tools or the well-meaning craftsman. Many organizations will also be quick to point out that Scala developers are more difficult to find (in comparison to Java, C#, JavaScript, etc) without acknowledgement of The Python Paradox, henceforth regarding Scala adoption as too risky.

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.

Olde Comments
  1. Rich Oliver says:

    I don’t need the JVM, but I do want a static, very strongly typed, multi-paradigm, multiple inheritance, object orientated language with optional garbage collection. Nothing else comes close to Scala in matching my requirements. Well with one exception: Dotty. The integration of type parameters and type members could be pretty awesome. But Dotty is not production ready, and is also a Martin Odersky led project.

    I would assert that potentially Scala is a very easy language to begin programming in. Inevitably at the moment the eco system doesn’t support new programmers like say Python, Java or even Ruby, but that is slowly changing and is not an inherent aspect of Scala. It requires a different approach. Beginners don’t need to be rushed into using best practice, difficult functional concepts are even complex object orientated approach. Beginners need to be allowed to discover the patterns in their own time. Then they will naturally start asking, isn’t there some to avoid writing this pattern (boiler plate) over and over again. Or isn’t there way to avoid getting this particular type of error over and over.

    So my contention is that the JVM is price worth paying for Scala, until such time as Scala (or Dotty) can escape its clutches. But in the meantime there are big pluses as well as negatives to using the JVM.


    • barnesjd says:

      Thanks for the insight, Rich. That is certainly a good example of where although it is a reason Scala MAY not be right, but the other advantages trump the caveat.

      I likewise agree it possesses great potential as a first language, with the multi-paradigm feature set being a strength as it imparts preparation for understanding a larger range of languages. As for the learning curve, perhaps I should call it an “unlearning curve”. The difficulties arise when approaching Scala after years of programming imperatively. I’ve lately observed that one of the biggest hurdles is the strong signal-to-noise ratio compared to busier languages like Java. Years of training the brain to ignore the noise causes Scala to be difficult because it is so terse and one shouldn’t dismiss any of the syntax.

      • Unlearning. Indeed!. I heard a guy on a podcast last year observe that Haskell is only difficult if you’ve spent years doing imperative programming, and had to unlearn in the sense mentioned above. If you’d started your programming career doing functional programming, then it’d be obvious. Maybe a stretch ( not done any Haskell myself ), but I could see the general point being true for the hordes raised on imperative programming.

  2. While the Eclipse Scala plugin is not perfect, I’m sure it’s (at least) useable. I’d love to hear about what problems you hit, and what version you were using.

    • barnesjd says:

      It was the most recent circa late 2013. It was indeed usable, but other than syntax highlighting, not much more than a text editor. The biggest problem was it liked to do excessive work in the event dispatch thread, hanging the UI for long periods of time making it overtly unusable. Phantom errors were quite common, but IntelliJ isn’t immune to those either. Overall, just felt like a round peg in a square hole. The nail in the coffin was the train wreck that is labeled as a CoffeeScript plugin.

  3. Ian says:

    I think Scala is actually a fairly easy language to pick up. Granted, *mastering* the language can take a long time (and I certainly haven’t mastered it yet myself), but I was able to pick up enough to start writing it fairly quickly. I think that people will do well to remember how long it took them to master C, Java, or even Python.

    As for the JVM, we can hope that they will start getting their head in the game soon. Remember, when Java first came out people laughed at its claim to being efficient, but now it’s fairly close to the efficiency of native code. With the introduction of the invokedynamic opcode in JDK 7, I think Oracle was starting to realize that the real strength of the JVM wasn’t as a platform for the Java language, but as a platform for languages in general. Now that there’s a pretty strong push for features like tail calls and reified types, and now that Java itself is starting to incorporate some more ideas from functional programming, I only hope that they’ll begin making the JVM a better platform for functional programming generally. Which would be pretty cool; a proper FP-supported platform that has the reach of the JVM.

    • barnesjd says:

      As always, thanks for commenting Ian. I probably should have been more clear that the challenges of learning the language I’m highlighting here are particularly for the droves of non-FP programmers like myself coming over and spewing WTFs all over the flatMaps, reduces, folds, etc.

      Obviously, I likewise hope the Oracle decides to invest in making the JVM more suitable as a general language platform beyond the Java language. I have in the past cited invokedynamic as a strong indication this could be the direction the JVM is beginning to take since Java has no use for it (not sure if that is still the case with Java8, tho). Perhaps we will get our wishes!

      • Ian says:

        Of course, getting into the functional mindset was the hardest part for me, as well. Maybe it’s because I love maths, but once I managed to get into the right mindset, the rest came quite naturally. I was staring at the first assignment of the Coursera course for a while, trying to do the problem with imperative control flow (and kept failing the style guide as a result), and then eventually something clicked and I rewrote the whole thing pretty quickly. Since then, functional programming has seemed just as natural to me as imperative programming.

        It sort of begs the question of what if someone learned Scala as their first programming language, without previous exposure to pure imperative languages. I suspect that it would be about as easy to learn Scala as it would to learn, say, Python. While mastering Scala may still take a long time, I think the basics are pretty easy to pick up once the “functional programming is really different” hurdle is cleared.

        I do find Java 8’s adoption of some functional ideas encouraging (now they need to add pattern matching for the trifecta); if Oracle doesn’t want to add FP features for the sake of general languages, they can do it for Java’s sake. Assuming that they are starting to make the Java platform more general-purpose, though, we can hope that they’ll give it quite a few FP features, since FP is starting to become more popular.

  4. kzvikzvi1 says:

    I am one of the strugglers on scala, and still struggling to get hang of it. We used it to a load testing and was super quick to use however I still dont feel that I know enough.

    • barnesjd says:

      Struggling is certainly expected. What I warn against is folks who struggle then begin getting angry about the decision to use Scala. As long as you have a positive attitude and a willingness to learn, I believe it will go well.

Tagged with: scala (41), functional-programming (31), agility (7)