FOSDEM

Martin Odersky will give a talk about Scala at FOSDEM 2009.

Could you briefly introduce yourself?

I'm creator of the Scala language and a professor at EPFL in Lausanne, Switzerland. Much of my work is about combining object-oriented and functional programming concepts. I co-designed Pizza and GJ, which eventually became the foundation for Java generics. I also wrote the original code of the current javac compiler.

What will your talk be about, exactly?

It gives an introduction and overview of Scala.

What do you hope to accomplish by giving this talk ? What do you expect?

I expect some parts of the audience will not know Scala yet. I hope my talk will give them some good ideas what it is and will motivate them to find out more. Others might already have used Scala a bit. I hope those will get a better sense of what more you can do in Scala, and what its design philosophy is.

What are the biggest advantages of Scala? And for which tasks should the language definitely be considered?

The three biggest advantages are productivity, reliability, and ease of conversion. Compared to Java, Scala reduces code size on average by a factor of two to four. Less code tends to require less work writing and maintaining it and also tends to have fewer defaults. Scala's strong static type system encourages solid designs and catches many errors already at compile time. At the same time, Scala is relatively close to Java. You can write Scala in the same style as Java, and gradually add more functional elements at your own pace. Scala is sometimes criticized by purists that it does not force a functional programming style on programmers. I think that's an advantage, and it certainly does make conversion easier.

For which tasks to consider the language? I'd say any task in a Java environment; the more challenging the better. Particular strengths of Scala come to play in support for concurrency, XML, GUI programming, or domain-specific languages. It can also do a decent job at scripting, but I would not use it in a job that requires only scripting and nothing else.

Functional programming is not yet a standard topic in computer science curriculums. Is the industry ready to use this programming paradigm?

I think the industry realizes more and more that a certain amount of functional programming is inevitable, if multicore computers should be used efficiently. Those who have made the jump also find that functional programming is a win in terms of productivity and reliability. So it's a classic adoption cycle, which starts out to be application-driven and continues because of design advantages. Object-oriented programming underwent a similar adoption cycle when it first came out. At first, it was the technique of choice for GUI programming, but very quickly the benefits of object-oriented modeling became a second and more important reason for adoption.

What are the biggest disadvantages of Scala at the moment and how will these be addressed in future versions?

The .NET version of Scala currently lags behind the JVM version. For instance, there's no Visual Studio support yet. The good news is that we have received funding from Microsoft for our ProgLab project, some part of which will be about improving Scala on .NET.

Is there good IDE support for Scala, for example in Eclipse or NetBeans?

There is now a fair degree of support for Scala in all three major IDE's: Eclipse, IntelliJ, and Netbeans. All three plugins are still rapidly developing, with new functionality being added at a quick pace.

In Erlang, multiple processes can share the same data within the same VM because the data are immutable. In Scala, pointers to (mutable) objects are sent between actors. So Erlang guarantees safe access to shared objects, while Scala doesn't and is thus prone to race conditions. Why this decision?

In Scala like in Erlang, it's usually immutable data structures that are sent between actors. The difference is that in Erlang this is enforced by the language, whereas in Scala it is a generally accepted programming policy. Why does Scala not enforce immutability of all data like Erlang does? The easy answer would be: Because Scala is interoperable with Java, it must deal with Java's mutable data structures such as arrays or hash maps. So global immutability is not an option. The more complicated answer is: Sometimes mutability is necessary to get really high performance. Imagine an image processing pipeline, where each stage is implemented as an actor. You don't want to copy images when sending them from one actor to the next; it would be too expensive. We are currently experimenting with effect systems that would let you better characterize what gets changed and what stays immutable. But that's still in the research stage.

Are there differences in what you can do with Scala on Java or .NET because of the underlying architecture?

Currently no, except for differences in native libraries. In principle, we could make use of .NET's reified generics, which keeps type parameters around at runtime. But it would mean forking the language, and there are some incompatibilities between .NET's generics model and Scala's. So we will probably keep things as they are.

What are the next steps in Scala language evolution?

In 2009 we plan to release version 2.8, which will likely have several additions to the current standard. For instance named and default parameters, trait parameters, virtual classes, and redesigned collections. We also hope to improve performance by specializing generic structures to primitive types. Beyond that, the focus will be on concurrency support. How can we program multicore computers and cloud services efficiently and reliably? Scala's actors will be an important part of this, but other constructs will probably come into play as well.

This interview is licensed under a Creative Commons Attribution 2.0 Belgium License.