1 2 next »

1. Scala Present
2. Scala Futures

Scala creator Martin Odersky - The H Half Hour

with Dj Walker-Morgan

The Scala language has become one of the most popular alternative languages on the Java Virtual Machine, blending two paradigms of programming, object orientation and functional programming, into one language. At Scala Days, a very busy conference in London dedicated to the language, The H got a chance to talk to Scala's creator about how the language works in practice and how it is evolving.

The H: One thing with Scala, that we hear, is that the choice of paradigms, object-oriented or functional, can become yet another thing for development teams to end up debating at an abstract level.

Martin Odersky: It's a constant worry. Let each team find their own guidelines on how they do that. I think its unfortunately inevitable. If we want to take programmers from where they are now with standard object-oriented programming and offer them this new dimension of functional programming there will be different ways to do things.

We can't impose the functional thing from the start because people wouldn't get it and it's not always the best solution; it depends on performance characteristics and things like that. So there are several ways to do things and it depends on the teams, the developers, to say "we value Java compatibility" or "conciseness" or "performance" or "semantic purity" or "functional programming" or it needs to be scalable, parallelisable – all these things are trade-offs. Maybe what the community at large can do is give a bit of best guidelines, best practices, to say "if you are coming from here...". That's a good way to approach the subject and there's currently not enough of that. We could definitely use more of these guidelines.

The H: With Typesafe bringing together a stack, one concern that came up was that it could be creating a mono-cultural stack with Scala being closely bound at corporate level. Are you concerned?

MO: I don't think it will be an issue. The stack is not just bound to Scala; people use it profitably from Java where it works well. The Play part of the stack is actually used more from Java than from Scala and the Akka part has quite significant Java usage. The second thing is that there are also quite a lot of other good libraries out in Scala; there are a number of web frameworks, not just Play, there's Finagle from Twitter which is mostly in the concurrency space like Akka is. So I think that, already, it's not a monoculture. There's a lot of users of other frameworks and I see the diversity increasing.

The H: One thing that surprises Java developers is that Scala doesn't have the same level of binary compatibility. How did you get this far with Scala without it?

MO: It's a tough problem. I think first – to put it into perspective – the standard people wish for is a very high standard. It's the Java standard which is the gold standard of binary compatibility, you could say, in that you can run a class that was written for Java 1.0 and it still runs today. Other languages are not like that, so you shouldn't try the same thing in C++ or even .NET. You shouldn't do that – there are periods where they say "recompile, it's a new age, it's a new era, recompile".

So Java is very particular (about binary compatibility) and that's a problem for us as the build tools assume a very high standard of binary compatibility and if you don't have that then the tools don't work the right way. So that's why people are often very concerned that Scala doesn't have the same high degree of binary compatibility.

We can't just change that out of the box. What we can do is a gradual process to more binary stability, but out of the box changing that would mean we freeze the standard libraries and even Java had to make some bad compromises there – java.util.date – we don't want another one that is around forever in the interests of binary compatibility.

The H: And we don't want a replacement like the other Java date and calendar classes...

MO: Exactly. So we want to be able to evolve and learn from the mistakes and do so in a managed way, which may involve recompilation on a major release. We will try in the future, two things, first to spread out major releases – right now, we have one every year; there's probably going to be a movement to have a schedule more like one every two years in the future. Second, to have cores of libraries for which we can say "these are mature now, we are going to keep them stable and you can bank on them".

The other solution we see is better tool support. We already have tools that detect binary incompatibility, so that's important so we can guarantee compatibility for minor versions. There are tools in prototype that heal binary compatibility problems through byte code rewriting. So we hope, with a combination of these things properly integrated with build tools, that the problem can be alleviated. I don't think it will go away completely and immediately, we have to live with that.

The H: Talking about slowing down the major version releases, will you be having long term support releases while keeping development releases rolling?

MO: Yes, that's actually the other part I didn't mention. Typesafe has a subscription model where we will keep stable releases with essentially a stable stream of bug-fixes and improvements for a number of years, so if a company wants to stay on a given version for whatever reason then they can do that now.

The H: Java – as a consumer of the Java ecosystem, how are you feeling about where the JVM is going at the moment?

MO: The JVM seems like it will get some interesting and welcome additions. The fact that there are performance improvements in every release is very good for us. But then, also, things that I've heard will come with JDK8 could be very useful for us; method handles, more flexible inlining strategies, possibly even the extension methods that they announced for Java 8, we will have to see how they play out, but they could all be very useful for future Scala releases. The problem we also have there is that Scala needs to run with a number of JDKs so we are, in the current version 2.9, still supporting Java 1.5. So it will take a while. In 2.10 we will probably drop 1.5 support.

Next: Scala Futures

1 2 next »