What Needs To Improve
DDJ: I'd like to go over some of the common complaints about Scala and get your feedback about them. The first thing that I see complaints about is the lack of binary compability between releases. Is that problem going away or, if it's going to continue, tell me why.
MO: We are working hard to address that problem right now. The problem with binary compatibility is mainly due to the fact that Scala permits libraries to evolve much better than Java. Essentially, the fundamental problem is that, with Java interfaces, you will never be able to add anything to the interface because you don't have control over who implemented it. When you change the Java interface, you have to rewrite all the implementations. Scala makes it much better and more flexible because you can add methods to a trait the analogue of an interface and you don't need to rewrite the clients because essentially the whole thing will continue to work. But you have to recompile the implementations of the interface. As a consequence, people in the Scala community take much more liberty in doing that because the barrier is not very high.
DDJ: So what are you doing to remedy it?
MO: We are working on a tool-based solution because we don't want to restrict the community from using this feature. The tool is based on binary class file rewriting. The compiler would do that automatically by going from an old version of the class to a new one, rewriting [the necessary parts.] And we plan to make that available as part of the TypeSafe stack.
DDJ: So, really, this binary compatibility problem is one of recompiling code that's been extended from previous versions?
DDJ: Scala uses a lot of characters with special meanings like Perl does and like Ruby is getting rid of. Do you see them as a problem you're going to get rid of or will they be part of the syntax going forward?
MO: That is all in the libraries because Scala does not really have operators. But as the libraries have evolved, there's been a strong consensus that we should be very careful with these things. There have been some very good usages for these characters and I believe, over time, people will get used to them. But certainly over time, we do not want to get further into that.
DDJ: In a recent post, David Pollak of the Lift framework complains that the multiparadigm design of Scala doesn't encourage a specific kind of style. And so there are people using Scala as syntactic sugar for Java, other people doing functional programming. Because of this, it's hard to know if you're using the right idioms and to read other people's code. How do you solve that when you have a language that's specifically designed to be multi-paradigm?
MO: I think David raises a very good point there. On the other hand, in that same blog post, he says that Haskell and other languages like that will have problems because they're too opinionated. So, whether you're opinionated or not, you lose [Laughing]. What we are going to do is a style-checking tool. I got some feedback the other day from someone who wants not only a style checker, but to know "where are we in the codebase? Are we functional, are we imperative? At what level of the Scala usage are we?" We can answer that with tooling, so we plan to integrate that in one of the next releases of the IDE. We'll include things you can customize and that give feedback for organizations that want to use Scala a certain way.
DDJ: So, enforcing a kind of Scala style.
MO: Yes. And we have a coding standard. It's important that we disseminate that as well. So we plan to have tools that are opinionated that tell you, "you should write this code this way."
DDJ: Will that coding standard be available soon?
MO: There is a Scala coding standard. That's our point of departure. I agree with almost everything in there.
DDJ: Another complaint is the slow compilation and interpreter.
MO: There are two factors in that. The first is start-up cost. Currently, the Scala REPL and the compiler take 3 or 4 seconds to come up. That's too long. We have recently cut that by more than half. It's not released yet, but we take this problem very seriously and we will get it done. There are some solutions now, such as the fsc compiler (Fast Scala Compiler), which essentially stays resident in memory.
DDJ: Is that part of the general distribution?
MO: Yes. We're also working on throughput to make big builds faster. It's hard. Inherently, we can't be as fast in terms of number of lines compiled as Java because typically Scala programs are a lot more compact than Java programs.
DDJ: Let's talk about tooling. It seems as though the Eclipse, IntelliJ, and NetBeans plugins are pretty much the top three IDEs out there. Are you going to be working on tooling?
MO: We've already put more than 1.5 person years into the new Eclipse IDE, which is currently in beta. I personally switched to the Eclipse plugin after 20 years of emacs. Certainly before then, I tried the plugin; but for the complex projects I do, it didn't live up to what I needed. Now, I would now never go back to emacs.
DDJ: I think that most people, once they leave emacs, do so permanently.
MO: Yes. But there will be some people who will not be happy with you for saying that.
DDJ: You just launched a new company, TypeSafe. What are you planning to do with it?
MO: We see a lot of demand for Scala and for highly parallel middleware on top of Scala from enterprises. This has convinced us that these things need reliable, long-term commercial support. So, we got together with the people behind the Akka framework, which is the most widely used parallel computation framework on top of Java, and we formed Typesafe to provide the developer tools, which will be open source and free, and the Akka/Scala stack, which is also open source. We'll provide support around these things.
DDJ: So, you'll be doing training, services, and tool development. Is that right?
MO: Tool development, training, and lots of support. We want to do subscription-based support, similar to the Red Hat model it's no accident that people we work with [are] at Greylock (the venture capital firm behind TypeSafe. Ed.). The lead investor is also on the board of Red Hat.
DDJ: I was just going to ask you if you're VC-backed. So does this mean you'll be leaving your teaching position?
MO: I took a leave from the EPFL in Switzerland to form the company. But I'll be back teaching in the fall if all goes well.
Future Versions of Scala
DDJ: Is there a .NET version of Scala planned?
MO: Yes. We announced it in July. We have a project, which is actually funded by Microsoft, to build a .NET version of Scala. And we have the first bootstrap version of the compiler compiling itself on .NET. There is still work to do, especially on Visual Studio integration.
DDJ: How about a compiler to native code. Is that on your radar?
MO: Well, that's interesting, I was attending a talk on this that I left to come meet with you. They're compiling to LLVM. It's being done by a company in association with the University of New Mexico. We'll have to see how that goes. The problem is one of resourcing. We can't do all the back ends at the same time.
DDJ: Very cool. So, what's going to be new in the next release?
MO: The next release will be v. 2.10, because v. 3.0, by our numbering scheme, would be backwards-incompatible and we don't want to do that at the present time. We'll have better support for dynamic languages, better reflection, and generally, we want to go into better support for parallelism. And also, we'll be working very hard on the next release of the Akka framework.
DDJ: Any idea of when that release will come out?
MO: We just released v. 2.9 and we generally have a year between point releases. So, in a year, but some of the features might appear in a minor release, such as v. 2.9.1.
DDJ: I noticed to my disappointment that the most recent release of Scala has four digits. You're going corporate!
MO: [Laughing] That was a hot fix. We shipped v. 2.9 with some problems that we discovered the day after we shipped and we had to do a quick fix.
DDJ: Well, good luck with all these projects. We'll be watching from Dr. Dobb's to see how these multiple endeavors work out.
MO: Thank you.