by Martin Odersky
The central drive behind Scala is to make life easier and more productive for the developer -- and that includes me. Scala does this with three principal techniques: It cuts down on boilerplate, so programmers can concentrate on the logic of their problems. It adds expressiveness, by tightly fusing object-oriented and functional programming concepts in one language. And it protects existing investments by running on the Java Virtual Machine and interoperating seamlessly with Java.
I have been involved with Java very early on, from Spring 1995, when it was still in alpha. My main contributions were the Espresso compiler, which became the core of Borland's JBuilder, the Pizza language which led to our work on GJ and ultimately to Java 5 generics, and the GJ compiler, which became Java's reference compiler javac, and which is used by almost every Java developer today.
About 10 years ago, I decided to take a step back and investigate what needed to be done to meet the next challenges in software development. Java was explicitly intended to be state of the accepted art when it came out in 1995: An object-oriented language with C-style sytax, single inheritance and interfaces. Since then programmers are increasingly facing new challenges for high-level domain modeling, rapid development, and, more recently, parallelism and concurrency. It seemed to me that a unification of the traditional object-oriented model with functional programming concepts was feasible and highly desirable to address those challenges. We first experimented with those concepts "in the lab", using an experimental language called Funnel. Once we were convinced we had the right mix of concepts, we decided to build a practical language on them, and that was the birth of Scala in 2003.
Scala took a risk in that, before it came out, the object-oriented and functional approaches to programming were largely disjoint; even today the two communities are still sometimes antagonistic to each other. But what the team and I have learned in our daily programming practice since then has fully confirmed our initial hopes. Objects and functions play extremely well together; they enable new, expressive programming styles which lend themselves to high-level domain modeling and and embedded domain-specific languages. Whether it's log-analysis at NASA, contract modelling at EDF, or risk analysis at many of the largest financial institutions, Scala-based DSLs seem to spring up everywhere these days.
Scala's unique combination of features also made it an excellent basis for concurrent, parallel, and distributed computing, which is widely thought to be the next big challenge in software development. Scala has a lot to offer in that space: from implicit parallelism in parallel collections to explicit concurrency using actors, it offers a toolset to write scalable concurrent applications simpler and with more confidence in their correctness. Scala's functional programming genes are an advantage here, because every bit of mutable state is a potential liability when it comes to parallelism, concurrency, and distributed computing. Scala does not prevent traditional imperative solutions, but its design encourages users to search for more scalable functional alternatives.
But the language is also a joy to use outside these advanced domains. It lends itself to any programming task, from one-line commands in the Scala shell to large mission-critical systems. In a nutshell, why do we do Scala? So that people like Graham Tackley, at The Guardian can keep saying "We've found that Scala has enabled us to deliver things faster with less code. It reinvigorated the team."
