For software development teams seeking new ways of approaching tough old problems, or simply innovative new ways of tackling entirely new problems,Scala is proving to be a language worthy of exploration. What was once an academic exercise in functional programming is now becoming recognized as a productive language across the IT industry. Scala itself has become wildly popular given its simplicity, functional approach, and ability to scale massively. But at the same time, there are Scala growing pains that adopters must learn to deal with as well. To become successful and maintain an enthusiasm for the language, development teams must learn to balance the good with the bad, and hopefully, the former will outweigh the latter.
Balancing freedom and control
I would say that Scala's sweet spot is a domain that has some actual complexity.
Jack Singleton, software developer at ThoughtWorks
It would be unfair to describe the Java programming language as restrictive, but the language was indeed built in such a way to help ensure that programmers don't get themselves into too much trouble. The inability to use pointers and the verbosity of Java's exception handling mechanism are two examples. Java has long been notable for restricting what developers can do in order to prevent developers from getting themselves into too much trouble. In contrast, Scala tends to show a bit more faith in developers than Java does, providing significantly more freedom. But this wealth of freedom can lead to issues in development. A wealth of choices can trigger confusion. How can this be mitigated? "Organizationally, you need to be in small, tight-knit teams. That's just going to make it a lot easier for everyone to stay on the same page. If you're trying to keep coding consistent across a team of 50 or even 20 people, that's going to become very difficult." Says Jack Singleton, a senior software developer at ThoughtWorks.
There's an operational aspect to consider as well. Singleton says that, ideally, you want to start working with smaller services. That's a smart practice no matter what language you're using. However, avoiding monolithic architectures might be even more important in Scala than in Java. Scala has a notoriously long compile time, which is still a very real problem. Singleton states that, in his experience, smaller applications and services that are factored out can have a reasonable compile time Scala, taking much of the frustration out of the development process.
Promoting innovation without creating chaos is another boon of developing in a modular manner. "The other thing is the flexibility of the language. It takes a little more work to keep a large project consistent. Ideally, you want to allow individual teams to come up with practices that best suit them. Keeping things in services adds a solid barrier between the code bases of different teams." Says Singleton.
Picking the right parts
Giles Alexander, a lead developer at ThoughtWorks, offers some insightful advice about making choices from a big picture Scala perspective. He mentions that forking this language into two parts is a strategy that is already being actively discussed. "I think that's probably what needs to happen. Scala communities readily admit that many parts of the language were mistakes that complicate things and dramatically increase build times. I think it would be a good idea to split there. But they're going to have to be quite emphatic about it to deprecate parts of the language effectively."
If the community leadership doesn't offer strong guidance, there's a real risk of repeating the issues that exist with the C++ program. C++ is such a large language that everyone has simply been encouraged to select the right subset to avoid known problems. Of course, everyone has picked a different subset so there is no consistency. Scala could well end up in the same boat, or the community could learn the lessons of C++ and get opinionated before it is too late.
Keeping maintainability in mind
This issue of fragmented language can happen at a small scale within an organization just as much as it can at the community level. It's important for developers on each team to make smart choices in their Scala code that make it maintainable down the road even if they leave the organization. Fortunately, Scala does have a type system to help make it inherently maintainable over time even with many individualized approaches.
As Singleton points out, "The type system has really tangible benefits, especially when it comes to exploring other people's code. You're relying a lot less on freeform documentation that someone hopefully has written (maybe not) and hopefully kept up to date (probably not). With a strongly typed language, a lot of this documentation is compiled with the code itself. It will not get out of date, and you can rely on it to tell you what a method is going to return and what you can do with it."
Selecting the best projects
On a final note, Singleton clears up a common misperception about Scala. The scalability inferred in the name has little to do with runtime performance scalability and everything to do with language structure. Scala programs can be built out in modules in a scalable way, so developers can assemble them without running out of rope. There will always be a way to connect all the parts of the system together.
"This is really Scala's forte. I would say that Scala's sweet spot is a domain that has some actual complexity. When you try to model complex domains, thinking about the domain and finding types that map onto your domain makes your code a lot more readable and a lot more maintainable." In the end, the goal of Scala is to make complex projects easier, not to simply make simple projects more elegant. Keeping this in mind, and forgiving Scala for a few misgivings, will go a long way towards maintaining an enthusiasm and affection for the language, and given how its popularity continues to grow, it would appear that the programming community is doing just that.