Editor's Note: This article has been republished with the permission of the original author, Graham Lea.
I’ve found this great Java library that can make developers more efficient in pretty much every source file they write. It has the following features:a broad and powerful collections framework:
- collection methods that greatly reduce boilerplate
- immutable collections that don’t have mutation methods (unlike java.util classes where e.g. List.add() throws an exception if the list is immutable)
- an awesome switch-like function that doesn’t just match numbers, enums, chars and strings, but can succinctly match all kinds of patterns in lots of different classes, even in your own classes
- an annotation that automatically writes meaningful equals, hashCode and toString methods for classes whose fields don’t change (without using reflection)
- a feature for avoiding the duplication between fields and constructor parameters by declaring fields in your constructor signature
- the ability to automatically generate property getters and setters at compile time
- the option to define default values for parameters of methods rather than creating lots of overriding methods to do the same thing
- the option of writing the names of parameters when you call a method to make your code more readable
- a solution for using mixins, i.e. multiple inheritance of method definitions (not just interfaces) without ambiguity/the diamond problem
- a nifty little class that avoids NullPointerExceptions by avoiding null altogether and instead expressing in your source code that you’re passing around or returning something that might not be present, forcing you to handle the possible ‘nothing’ but only when you want to use it
- a way to give the appearance of adding new methods to existing classes (only where you want to use them), similar to C#’s extension methods and Objective-C’s categories.
- the ability to easily pass around blocks of code for other classes to execute (without having to wrap them in a Callable class and a call() method signature)
- some neat features for doing easy concurrent programs like parallel collections and an actor package
- like all good libraries, you don’t have to convert your whole system to use it all at once; you can just use it in places where it makes the most sense to begin with. It will integrate very smoothly with all your existing code.
There are of course a few costs that come along with the benefits of using this Java library, but they’re fairly minor:
- Your developers will have to learn how to use it. True of any new library you introduce to your team, really, and the efficiency gains will outstrip the learning cost pretty quickly.
- Your code will look a bit different. This might take some people a bit of getting used to, but part of the reason it will look different is because there’ll be less code to write, so the Dev team can get more done.
- If you’re growing your team, there may not be heaps of developers in the market that have experience with this library, but if you make a habit of hiring really smart programmers who can do pretty much anything you throw at them (that’s the approach we take at Tyro), then this shouldn’t be a problem.
Personally, I think this library is a godsend, and I think there’ll be a LOT of teams picking it up over the next five years, just like the popularity of Spring has swept the globe due to all the efficiencies it bestows on developers. The library, by the way, is called ‘Scala‘, and it was invented by a guy called Martin Odersky. Scala has been in development since 2001 and it’s …..
Hang on, there seems to be a question up the back. Yes? …..
Okay, the question is, “Isn’t Scala a language?” Well, of course it is. That’s what I’m talking about. The Scala language….
I’ve been calling it a “library”? Have I? Oh, sorry, I didn’t realise. Well, yes, you’re right, it is a language, although it also has a large useful library as well. But seriously, mate, what’s the difference?
SERIOUSLY, WHAT’S THE DIFFERENCE?!
Take a step back and think about this for a second: Why is it such a big deal to start using another “language” on a project, whereas for a “library” or “framework” the decision is much easier?
I know there’s sensible arguments we might use against employing a new language:
- There’s a learning curve for developers who haven’t used the language before
- There’s a technology risk if the language contains serious bugs or ceases to be supported
- There may be difficulties integrating the language with existing code
- If you decide to stick with the language, there’ll provably be legacy code from previous languages for a long time
- It’s harder to hire developers who already know the language if it’s relatively new or novel
All of these are valid concerns and worth thinking about, but all of these concerns can just as easily be levelled at libraries and frameworks. (Read through the list again, but replace “language” with “framework”.)
My real issue though is that this dichotomy is false. There isn’t a separation between libraries, frameworks and languages – it’s actually a sliding scale. What we’ve traditionally called libraries and frameworks will these days often introduce significant changes to the style of a codebase and even bring languages of their own tailgating in behind them.
Two examples of this are Hibernate and Spring: great projects, widely-adopted, delivering huge productivity gains. Hibernate brings with it HQL, a new language, similar to SQL, but different in the details. Employing Hibernate also means placing annotations throughout your domain model code. While the syntax of annotations is part of the Java spec, the number and complexity of annotations included in a spec like JPA 2 mean that they become a language unto themselves – a non-Java language that just happens to live inside our .java files. Similarly, Spring does a lot for us by enhancing plain old Java classes, but the mechanisms for defining the enhancement are a language of their own, either in the form of <bean> configuration XML files or, again, using a suite of annotations.
As we’ve adopted these frameworks over the past decade, we’ve all changed our code to look vastly different to the Java of a decade ago, but we’ve embraced these changes because of the productivity the technology has delivered. Yet, when presented with the idea of adopting a new core language that would deliver similar productivity benefits, many teams baulk at the idea because… well, it would make the code look different!
What Are You Going To Do?
If Scala really was a “library” that was able to deliver all the benefits that I listed above, wouldn’t you and your team be desperate to start using it? And yet, because it has the label “language” attached to it, many people don’t even consider the possibility of using it, let alone whether the benefits outweigh the costs. It’s time to stop the xenoglossophobia (other language scardey-cat-ness), rise above the fear of learning something a bit different (because we’re doing that anyway!) and start evaluating all technologies on their merits.
And once you’ve thought about that for a while, start coding in Scala.
Update: If you’re a Scala programmer reading this, I’m now running a short survey to get some numbers around whether Scala really is more productive. Would love it if you could take 2 minutes to contribute.