The latest expert opinions, articles, and guides for the Java professional.
Disclaimer: According to British scientists, the author is descended from apes.
In Part 1 of Scala: Sink or Swim? we looked at some things you should ignore in the Scala ecosystem when you are starting to adopt Scala. I think it was important getting that out of the way first — if you discover these things as you’re learning, thinking that’s idiomatic Scala, they might scare you off, and you would be missing out, in my opinion.
In this post we’ll look at some more things that are not quite perfect in Scala land, but that you must simply live with, at least for now. Finally, in Part 3 of this series, we’ll peek at some language features that form a simpler subset of Scala, but still make learning and using Scala worthwhile.
Things you must live with
Any language has some annoying warts — you just learn to live with them. I think it’s a good rule of thumb to avoid the things mentioned in the previous posts at least initially, and decide whether you want to use them after becoming comfortable with the language. Or maybe you already are on good terms with some of them — I’m not trying to change your mind about that. If not though, keep in mind that these things are also part of the Scala community in it’s diversity, and ignoring them completely might not work as well when you find that, for example, some of the Scala answers on StackOverflow or on the mailing lists are of the opposite mindset.
But you should totally be able to coexist with the “deep end” of Scala and still write good code that is not too foreign even to Java developers. There are many libraries in Java that I can’t stand or that are internally divided into so many layers of abstraction that they are extremely hard to debug or understand, but that doesn’t take away from the value of Java itself.
The same is true for Scala, but as a newer and less popular language than Java, there just isn’t a comparable number of libraries that are really solid.
Comparatively, Scala is still in the early days where Java would’ve had EJB 2 and Struts 1 as the pinnacle of web development. The language is still that young, but perhaps this comparison isn’t quite right — I don’t think Scala ever really had as big of a blunder as EJB 2, and web development with Scala is not necessarily behind or ahead of web development with Java.
But there’s still a lot of exploration and mapping of the territory going on. In the Java world, most people would not blame the Java language for EJB 2. They would just stay clear of that single part of it. But with Scala, some folks are quick to blame the language or the community and ecosystem as a whole for any particular misgivings.
And the Java world still hasn’t reached a consensus on the eternal question: which web framework to use? And it never will, because no single framework is particularly amazing, for one reason or another. Different variables weigh into that choice each time.
So, I’ve done my best to narrow down the main unavoidable issues into 4 areas:
- Binary Compatibility
- A good IDE is pretty much a requirement for understanding some code
- Compiler speed in conjunction with IDE use patterns can slow you down
- Scala is still evolving and getting new experimental features
This is perhaps the biggest issue with Scala. Libraries compiled with one version will not necessarily work with the next or previous versions, so they need to be recompiled with each version upgrade. SBT can do this (compile against multiple Scala versions), and I think that has been one of the main contributors to its relative popularity.
If some libraries don’t recompile, they will hold back users from moving to newer Scala versions, or alternatively force users to use source dependencies or even resort to forking. But things have been getting better even on the binary compatibility front.
Some would likely disagree, but I think you definitely need an IDE for developing Scala code, and maybe even more so for reading code written by others. It is not as easy as in Java to immediately see what a particular line of code does, due to more constructs being available (such as implicit conversions and type inference). An IDE that lets you jump to declarations and shows types when you hover over something with an inferred type is essential in understanding some Scala code.
Thankfully, the Scala IDE for Eclipse is quite good since version 2.0, and I hear the IDEA plug-in might be even better.
This is the largest issue that remains with tooling IMHO — when you have a project with thousands of lines of code and use Build Automatically in Eclipse, you might end up in situations where changing a single line + saving will result in half a minute of waiting. Compiler speed is also something that is being worked on.
New features will be added to next versions of the language, potentially including value classes (yay!), control structure syntax improvements and even compile time meta-programming. This can seem kind of scary, especially the last bit, which is also known as… oh man, I don’t even want to say that word (macros). In reality, that change will likely be optionally enabled and not exposed to most users.
Plus, there already are a many features in the language that you shouldn’t use without good cause, as mentioned earlier. Josh Suereth pointed out some more in a comment to a previous post, such as vals/vars in traits (due to issues with initialization order). I just hope that library authors are not too eager to jump at the chance of experimenting with every new feature where they could do without. Of course, that doesn’t go for everything — some libraries may really benefit from these language evolutions.
There is even a new proposal for disabling some language features by default, which generated a huge comment thread on the mailing list. Seems that many expert users think it is too much of an inconvenience to have to enable those features everywhere they need them. I don’t have a particularly strong opinion on the matter, but I’m not totally against the idea that some devices for shooting yourself in the foot should have safety locks.
As a bonus, the best comment from that thread:
Don’t worry. Loops will be optimized in 2.10.
This is about the for loops vs. while loops issue I mentioned briefly in the last post. It will be great to see this being improved finally.
Update: some more developments on the mailing list. It seems the main reason for the proposal is a longer term direction for Scala that has the potential to unify some of the hairier features of the type system into a simpler set of rules.
There are some issues everyone in the community must live with when they use Scala. In my opinion, it is not too much, considering the power you are getting from the language.
I previously alluded to a division in the community (and my earlier post probably didn’t help it). Some people with functional programming background seem condescending at times, and probably think that the OO guys don’t care enough about writing better code. Many potential Scala programmers with OO backgrounds care about creating large code bases that are maintainable by any able team member or new hire for years to come. And until the functional side has proven to the wider community that programs written in the functional and more abstract way are as maintainable, their voice will not be taken too seriously by the larger group.
It’ll be interesting to see whether the functional/theoretical and OO/pragmatic side can achieve a more symbiotic co-existence and further bridge the functional / OO gap, or whether the groups will diverge even more. In any case, I think it helps if you know about this division when you start with Scala. Get comfortable with the basic language features, and then decide whether you and/or your team wants to keep avoiding the other side, or start expanding your horizons further.
Keeping in mind that I’m more of OO background, I think what the Scala community needs most at the moment to make Scala an even better Java alternative is to bring in more pragmatic programmers who would write solid libraries that don’t overuse symbols, avoid some of the more complex type system features, maybe even stay more imperative than functional (while still preferring immutability), and don’t go overboard with the type safety.
It doesn’t mean the more pure/functional/type-theoretical/experimental/research side of Scala should go away — they should all be able to co-exist in some kind of symbiosis.
I think this has been happening and will continue.
Look for more in Part 3…
In Scala: Sink or Swim? Part 3, I finally get the all the great things about Scala, and why I even started playing around with this interesting language in the first place.
Thanks for tuning in! If you have any questions, post them in comments or drop an email to email@example.com. In the next and final part we’ll take a brief look at the Scala features that are probably the reasons Java programmers should learn Scala in the first place. These form a subset of the language that is actually relatively simple, but still quite powerful.
Leave a comment