Martin Odersky gave a talk on the Scala programming language at last week's JavaPolis '07 conference. Following the talk, the JavaPosse interviewed Odersky about various aspects of his work on Scala and functional programming.

In the interview, Odersky talks about the origins of Scala in the Java compiler, javac, and the Java generics that he worked on for Sun in the late 90s:

Doing the [Java generics] work, I got somewhat frustrated. Java is a very nice language, but it does impose a lot of constraints when you want to want to add new stuff...

To do a good job, we really needed to integrate functional and object-oriented programming further. We [realized] we should drop some baggage. And that was the Scala project, where we said we wanted to keep bytecode and full library interoperability, but we wouldn't be completely compatible with Java source code. A lot of things are similar [to Java], but it's not the same [language].

The JavaPosse asked Odersky if he thought Scala could become a general-purpose language and even a replacement for Java:

Yes, most emphatically, yes, it can [replace Java]. If you're a competent programmer, you should have no problems getting into Scala. It should increase your productivity very quickly...

The main different between Java and Scala is that Java has a lot more boiler plate. Boiler plate is a nuisance for competent programmers, but it can be a big help for newbies because if you're a newbie, [boiler plate tells you that] you have to write this, then this, and then this, and there is not a lot of thinking you have to do.

Odersky also talks about why Scala is a practical approach to functional programming:

Some people say that Scala should have been a nice purely functional language, like Haskell... and that it was watered down to play in the Java pound. But I don't agree with that. Scala tries to be something different [from pure functional languages]... What we tried is to find this fusion of functional and object-oriented programming.

One of the key tenets of functional programming is that functions hold very little state: instead, of they operate on some input, and return an output value. The JavaPosse asked Odersky why he thought immutable objects were important:

First of all, objects in Scala can be plain, mutable objects, like in Java. There is no problem with that at all. But we recommend that if you can make [objects] immutable, that's good, and you should try to find out where you can make objects immutable.

The first reason [why we recommend that] has to do with parallelism and multi-core. If you have an immutable object, you don't have to lock access to that object. It doesn't need to be synchronized because ... it doesn't change. So everybody can access the same object. The more immutable objects you have, the better your application will parallelize. That's true whether you do it with threads, with actors, or with software transactions, that's the underlying thing that always holds true. The more state you have, the more trouble you have when you parallelize things. State, mutable objects, become more and more an efficiency bottleneck.

[Stateful objects] used to be a shortcut for efficiency. You couldn't create new copies of objects because that was too expensive. But it actually has turned around, even for single-threaded code. If you change an object, modern garbage collectors have to do a thing called card marking, which is incredibly expensive. The more you change fields, particularly of old objects, your performance is going to suffer. So it turns out that it's actually better to have immutable objects.

What do you think about Odersky's observations on Scala?