JVM Languages

Interview with Scala's Martin Odersky

What Scala did right, what needs to be improved, and where the language is headed

Martin Odersky, the developer of Scala, was recently in the Bay Area to kick off his new company, Typesafe. He sat down with Dr. Dobb's Editor-in-Chief Andrew Binstock to discuss the language, its beauty and its warts, and where it is headed.

Scala Today

DDJ: 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?

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.

DDJ: 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.

DDJ: 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.

DDJ: 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.

DDJ: 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.

DDJ: 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.

DDJ: 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.

DDJ: 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.

Syntax

DDJ: 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.

DDJ: 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.

DDJ: So, it wasn't just a personal preference.

MO: Oh, no, no.

DDJ: 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.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!