Martin Odersky is creator of Scala, a statically typed, functional and object-oriented language that produces bytecode for the Java VM. He is also author of Programming in Scala.
Artima caught up with Odersky during JavaOne 2008 and asked him to compare Scala's design philosophy from the programmer's view to that of Java. We also asked him to explain Scala's approach to concurrency:
Frank Sommers: One way a programming language's philosophy manifests is by the language encouraging certain development styles or tendencies. A language does that by making certain things easy, and other things harder, for the developer to do.
What would you say are the sort of tendencies Scala encourages in that manner, especially in comparison with Java? What are some of the things Scala makes easy that require more effort to do in Java and, vice versa, what are some things that are easy in Java, but that Scala makes harder?
Martin Odersky: Scala makes almost all aspects of programming easier than Java. Whether it's about writing a small script, defining some simple classes, or constructing a very large framework, Scala lets programmers express themselves faster and more concisely.
There are also many areas where Scala makes things dramatically easier than Java. For instance: Decomposing symbolic data, defining your own control abstractions, designing high-level libraries that are really flexible to use, writing component frameworks, designing embedded domain specific languages, or going from rapid prototypes to reliable high-performance applications.
Scala does not enforce any particular programming style, but it encourages functional object-oriented programming. Its higher-order functions and pattern matching, and its emphasis of immutable data, makes programming in a functional style more convenient than in Java.
The only aspect I can think of where Scala makes things harder than Java are convoluted control constructs. Scala lacks
continue statements, and it does not let you fall through from one case in a
switch to the next. This encourages programmers to keep control constructs simple. With Scala's nested functions, tail recursion and closures, it's usually easy to find a better solution by splitting the program logic into several functions.
Frank Sommers: What is Scala's current approach to allowing developers to build reliable concurrent applications? What are some of the design philosophies that Scala's concurrency-related constructs encourage?
Martin Odersky: Scala does not contain a fixed concurrency model. It can work with Java's standard thread model, as well as with other approaches to concurrency. Everything is done in high-level libraries, which Scala makes very easy to set up.
That said, currently by far the most popular approach to concurrency is Scala's actor library. This provides for threads that communicate by message passing. Messages are asynchronous, and the receiver of a message can control with pattern matching which kind messages it is prepared to act on at any time. This is almost exactly the same approach as the one followed by the Erlang programming language. I often hear the argument that Erlang-style actors could also be emulated in Java or other programming languages. I don't think this is true. To precisely emulate these actors, you need pattern matching, and only very few languages provide that.
There are also several other possible approaches to concurrency, for instance, futures, transactions, or lock-free data structures. Scala supports all of these seamlessly by adding new libraries.
It's probably too early to tell where concurrent programming is headed. It might be a combination of some or all of the mentioned concepts, or something completely different might develop. Whatever happens, Scala is well-placed to express new concurrent techniques, because of its focus on functional programming and immutable data, and its approach to library-centric design.
What do you think of the coding and design tendencies Scala encourages?Post your opinion in the discussion forum.
The Scala language home page:
Programming in Scala by Martin Odersky, Lex Spoon, and Bill Venners
Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.