The latest expert opinions, articles, and guides for the Java professional.
“Scala has evolved a lot since its inception in 2004. Its user base has grown to a size I could have never imagined back then, and has been picked up in industries ranging from major enterprises, financial institutions, to startups. Being recognized by RebelLabs is a huge honor and validates the work we’re doing to create an elegant and powerful programming language.” –Martin Odersky, creator of Scala
In our recent publication 10 Kick-Ass Technologies Modern Developers Love, we selected a group of tools that developers have proven to really enjoy (based on a heady mix of market data, community activity, anecdotal evidence, our own experiences and a general gut feeling). With Scala as the 1st choice of alternative JVM language to learn, we wanted to get a few more details from the coder perspective about Scala. So, we reached out to Typesafe and sat down with Adriaan Moors, Scala Tech Lead, and asked a few probing questions…
Q: What developments in Scala would you love to see?
Adriaan: “The development I anticipate most is for Scala to go massively mainstream. This is why we’ve been focusing on documentation, stabilization, polish, as well as making it much easier to contribute to Scala’s core, so that development of the Scala project can scale with the increased demand.
Concretely, during the development of 2.11, we’ve been preparing for an increase in contributions through modularisation and automation (from validating pull requests, to publishing a release), and will continue this effort in 2.12 with a standard sbt build for the compiler and the standard library, for one.
It’s great to see maintainers stepping up for the modules that were spun out of the core in 2.11. This trend will continue, and I also hope more people will get involved with core Scala development. The core team will of course continue to lead the effort and shepherd the project, but a lot of cool things can be done on top of the Scala platform.
I’d like to keep improving the compiler as a platform: we’ve had compiler plugins for a long time, but they are pretty heavyweight. Extending the language became much more practical through macros (they are intentionally strictly limited in how they can change the language). Tools will also increasingly leverage the compiler itself. For example, we’re working on exposing sbt as an (incremental) build server to IDEs. Finally, we’re building an extensible style checker on top of the compiler, which will allow teams to express and enforce their own Scala style.”
Q: What do users ask most for in future versions?
Adriaan: “They want us to speed up and polish our tooling (compiler, build system, IDE, documentation tools, style checkers,…), and so do we! All development at Typesafe is done in Scala, using the same toolchain our users rely on.
The other requests fall in the same category of stabilization: improved documentation, simplification of the language.”
Q: What factors do you believe are most responsible for the success of Scala?
Adriaan: “To me, the most compelling interpretation is that Scala is a unifier – along many axes. Developers don’t want to have to chose between easily writing small abstractions (functions) or big ones (traits). Experiments in the REPL or the worksheet tend to grow into medium-sized scripts that go on to become real products. Scala supports the full spectrum of development here as well.
Library authors need powerful abstractions (type constructor polymorphism, implicits,…), but clients of these abstractions shouldn’t have to be burdened by them (powerful type inference, and again, implicits work hard behind the scenes).
Finally, Scala is simply fun to program in, due to all of the above as well as (last but not least) its compact and regular syntax.”
Q: What do you see happening in the future of your technology segment in 5-10 years?
Adriaan: “Functional programming will seem completely obvious and will be generally accepted by the majority of professional programmers, much like what happened for OO.
The next step (or current challenge, for many early adopters) is about establishing a culture, developing good intuitions for when to use different abstractions. Instead of trying to define FP precisely, I think we’ll evolve to answering more interesting questions, like how and when to apply the tools it gives you. This is what Scala is all about: it gives the programmer a rich variety of powerful abstraction-building tools, but it can’t tell you when to use which one. That’s where our experience (captured as a programming culture) comes in. We can’t automate it all.
Concretely, I expect we’ll refine advice like “never mutate” or “everything’s a monad”, just like OO’s early “just use dynamic dispatch” and “everything’s a Visitor” mantras have blended with a richer, more subtle, set of techniques and patterns. Although it’s good to have a shared vocabulary (like the GoF’s design patterns), the challenge is to develop intuitive answers to more nuanced questions like “When is it okay to mutate?” or “Which is the right tool to capture commonalities in this code, while expressing clearly the intent of the essential differences?”
FP underpins many solutions to the current challenges in software design. It’s a natural fit for Reactive Programming’s event-driven model, since functions are at the right level of granularity to describe reactions to events, and to compose them. I think we finally have enough RAM & processing power, low latency connections, and, most importantly, the demand to apply the ideas of functional reactive programming and stream-based processing, acknowledging that the world and the systems we build are fundamentally asynchronous and event-driven.”
Big thanks to Adriaan for his responses and giving us a clue as to what to expect from Scala in the future. Check out the complete report below to see the section on Scala and the other tools that modern developers love! :-)
No comments yet.
Sorry, the comment form is closed at this time.