Ref : scala-wiki scala-lang
Interviewer : There are lots of languages coming to the JVM (JRuby, Fantom, Clojure, Gosu, and so forth). How is Scala different and how will it escape being a niche language?
Martin Odersky(MO) : How will Scala compare to the other languages? First, there's a big divide between statically typed (which typically goes along with a fast runtime) and dynamic typed (which typically goes along with being a little slower). Scala is one of the few statically typed languages on the JVM. The other big one, of course, is Java. It's true that there are some other statically typed languages coming out and we'll have to see what kind of traction they get. Scala, however, was the first statically typed alternative. The other big thing for Scala is that it combines the OO model of Java with functional programming. And it's the only language to do so. The other functional language on the JVM is Clojure, but Clojure sheds the OO model.
I : Sheds it completely, yes.
MO : And Scala doesn't do that. We think that the biggest gains are in the combination of the OO model and the functional model. That's what we firmly believe is the future.
I : Do you expect then that the Scala model will mostly consist of the hybrid model or is part of the effort to encourage people to adopt a mostly functional programming model?
MO : I would contest that it's a hybrid model. I think it's really a fusion. It's not a mixture of two things; a new kind of program, which are both objects and functions. The one thing that you tend to give up more and more is objects with mutable state. That's sort of the old, classical kind of object model, which you can still do in Scala. But it's true that the trend moves more and more away from that to the purely functional. Once you do that, there's no mixture at all between the two models.
I : On the Scala website, you list the qualities of code associated with increasing expertise in Scala. It seems to get more functional as one becomes more expert.
MO : Of course, that's true: Because at these levels of expertise, we took as a baseline somebody coming from Java, so with imperative code and mutability — "that's what I know." It's true that to become functional, for an individual to get deeper into Scala, most people would start off with the more imperative side and then progress towards the more functional side. Imperative and object oriented are two different things.
I : Are there niches where you're seeing Scala being strongly adopted? Like Erlang with telephone switches: Are there areas that are a particularly good fit?
MO : There are two market segments where Scala is leading relative to the others and one is Internet companies; in particular, Internet companies that need to scale rapidly. Examples are Twitter, LinkedIn, Foursquare, and many others. The other big market is in finance. They are more discreet; I can't talk about much. But there are some very high profile projects. For example, at UBS, it's approved for general production usage there. There are many other projects in risk analysis, contract modeling, etc.
I : Is the scalability you're referring to due to the built-in actor syntax?
MO : The actor syntax is actually not built in. It's a consequence of the fact that Scala has very high abstractions for syntax. It's a pure library. So, it's actually not built in.
I : OK, so...
MO : It's actually much more than that. Scala is built on a very fast runtime, the JVM. Being functional, Scala sheds a lot of the liabilities of imperative code, which becomes very, very serious as you go parallel. If you want to go parallel, either implictly with the parallel collections or explicitly with actors, anything that has state change becomes an increasing liability for reliability and sometimes even performance. So essentially, it's the functional genes of Scala, coupled with the fast runtime that makes it a very good contender.
I : It seems that any functional language running on the JVM could probably attain the same kind of scalability you're referring to. Would you disagree with that?
MO : I would disagree with that. Because if you look at the actual code out there, like the collections that have become parallel in Scala 2.9 and will be distributed in one of the next iterations or the actors, they are really extremely expressive and they make essential use of the object-oriented features in Scala. Without those object-oriented features, we could not have built these sophisticated ways to express parallelism.
I : Talking about the syntax of the language, when I look at Scala code, I feel like I'm reading backwards. The return value is at the end of the declaration, and the types are declared after the variable names. Was that an intentional design to move away from Java and C-like syntax? Why did you choose to invert the positioning?
MO : We're not the first to do that. There are many other languages that do that: Pascal, Modula, Ada, and lately, Go. There's a whole language family that does it the Scala way. It's true, though, that the dominant languages — C/C++/Java — put the type first. I think that was a very good decision at the time C was created — actually, C got it from Algol 68, as far as I know — to put the type first. In the early days, the types were very short keywords like
int, or long, or float. Essentially, for the price of one, you got two things: the start of a new definition, and what's the type of the thing.Nowadays, things have changed a lot. First, a lot of our types have become a lot bigger. We have a type, which is a hash map of strings to a list of booleans [holding out his hands wide apart], and then comes the thing you define at the very end. The type of the thing you define should be the important thing. The second thing is that, quite often, this type (whether long or not) can be inferred, which means it goes away completely. A lot of Scala code is that way.
I : Yes
MO : Then you have to invert things. When the type is gone, you have to put something in its place. So, we decided to do a very regular syntax, which says that we always have a keyword first, which says what kind of definition we define: Is it a method? a mutable value? Is it a variable? Then comes the name, then comes the type. So that's why we went that way.
I : So, it wasn't just a personal preference.
MO : Oh, no, no.
I : What about the use of capital letters on the primitive types? Why is
Int not just int? I'm curious because there are several other languages based on the JVM that don't pass through…MO : On the first iterations of Scala, we did write lower-case
int. At some point, it stopped looking right and we converted to the initial upper case. It's mainly in Scala that the primitive types are actually not primitives. They're object types, so it didn't seem to make sense to give them the syntax of other types. We wanted to emphasize that they're types like any other object.I : 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.
I : 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.
I : So, really, this binary compatibility problem is one of recompiling code that's been extended from previous versions?
MO : Yes.
I : 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.
I : 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.
I : 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."
I : 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.
I : 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.
I : 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.
I : 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.
I : 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.
I : 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.
I : 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.
I : 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.
I : 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.
I : 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.
I : Understood.
MO : One of the things coming up is Scala for JavaScript.
I : 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.
I : 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.
I : 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.
I : Well, good luck with all these projects. We'll be watching fromDr. Dobb's to see how these multiple endeavors work out.
No comments:
Post a Comment