Ahead of tomorrow’s expected announcement and amidst last week’s QCon London conference, InfoQ received an invitation to sit down with Martin Odersky to discuss both Typesafe Stack 2.0 and Scala. In the following interview Martin discusses the future of Scala, draws the comparisons between F# and Scala and addresses, once and for, all the question of breaking binary compatibility.
Martin, is of course, the creator of the Scala programming language as well as the Chairman, co-founder and Chief Architect of Typesafe. He is also the author of "Programming in Scala," creator of javac and scalac, and was a student of Niklaus Wirth, the creator of Pascal, at ETH Zürich where he received his doctorate.
InfoQ: Let’s get the easy questions out of the way. First, can you tell us what you’re working on right now?
Martin: I'm putting the finishing touches on the implementation of the value class proposal, Scala Improvement Proposal 15. The idea is to have extremely lightweight classes that do not need object allocation for their instances. Interestingly it can be done without introducing new
syntax in Scala.
InfoQ: Typesafe has garnered a great deal of attention since the company formed and recently there were two big announcements: The first release candidates for both Akka 2.0 and Play 2.0 were announced. How stable are these releases and what are the timelines for the future?
Martin: Both releases went through several betas before. Our release candidate process is pretty rigorous. So I believe once they come out in final, they will be stable. The next major milestones for them are in the summer, when they will be integrated with Scala 2.10. After that, we plan to add a new database backend in fall.
InfoQ: Some high-profile companies like Twitter and the Guardian who are both speaking at QCon London this week have made huge investments in moving to Scala. Can you tell us about this, and can you tell us what input these users have had on requesting new features?
Martin: Scala has worked well for Twitter and the Guardian, and many others like them. As Graham Tackley, the Guardian dev lead wrote: "We've found that Scala has enabled us to deliver things faster with less code. It's reinvigorated the team." Generally these companies are happy with Scala's feature set. They have prompted us to work on better tools, such as better IDE support, which we delivered. We are also working with Twitter and the Akka team on a common concurrency foundation that can be used from both sides.
InfoQ: One question on the mind of the development community has to do with the compatibility of Application Binary Interfaces (ABIs). As Alex Blewitt reported, Scala breaks binary compatibility with each new release, forcing developers to compile from source to port applications between operating systems. Will this be addressed at some point, and if not, why not?
Martin: Scala currently breaks binary compatibility with major releases. Minor releases have been binary compatible for a while now, and we do verify that with the help of a tool. When discussing binary compatibility there is a tension between the desire to keep things stable and the desire to improve APIs with new and better functionality. We do not want another java.util.Date in Scala! Right now, Scala strikes a balance in maintaining binary compatibility for the duration of a major version. We will gradually turn the dial to more stability, by having longer major version intervals, having a gradually increasing core of libraries which will kept stable from one major version to the next, and offering tools that help in migration through automatic bytecode rewriting. Besides, Typesafe is offering subscriptions to stable versions that will be kept current with bugfixes for a number of years.
InfoQ: Following up on the previous question, could the Java 7 invokedynamic combined with method handles help with binary compatibility. Could a future Java 7+ Scala use them?
Martin: I do not see how method handles would help; and, besides, migrating to them would itself break binary compatibility! One of the key challenges for binary compatibility are posed by traits, Scala's richer version of Java's interfaces. They make it easy to add new methods to an existing API, which is something you cannot do in Java without rewriting client codes. In Scala you can do this, but it requires a recompilation. The point is, because the bar for API extension is so much lower in Scala, people, tend to do it more than in Java, and that's what's causing binary compatibility problems. So, a way to rewire traits on the fly without requiring recompilation would be a definite help. The extension method proposal in project Lambda comes close but unfortunately falls short of being able to support all forms of traits.
InfoQ: Perhaps because of Scala.Net , there there seems to be a desire to compare Scala to F#. In some ways this is comparing functional programming to object oriented programming. Do you see it that way? What are the comparisons and what are the compromises?
Martin: Scala and F# share many aspects. Both are statically typed, functional/object-oriented hybrids on a mainstream platform. Both have innovated in language design and some innovations are independent realizations of similar ideas. For instance F#'s active patterns are analogous to Scala's extractors, and F#'s workflows fulfill a role similar to Scala's delimited continuations. The main difference as I see it is that Scala understands itself foremost as a modern object-oriented language in which you also can do functional programming. The way I read F# is that it sees itself foremost as a functional language that also supports the .NET object model. But F# is more conservative than Scala when it comes to object-oriented innovation. In terms of measures such as grammar size, Scala is also somewhat smaller than F#.
InfoQ: There has been some debate in the Scala community about the need to add features versus keeping it lean. Can you give us a sense of where Scala is headed? Does Scala need to become a bloated multiparadigm and multipurpose language to be considered mainstream?
Martin: I think the consensus is very much that we keep it lean. Scala is a compact language despite its enormous spread of use cases because it has always tried hard to unify things. The same concepts describe objects and functions and components. Instead of adding features, Scala has very powerful abstraction capabilities that let users define similar features themselves in libraries. In the future my ambition is to make Scala an smaller language, not a larger one. I know it is hard, but we will try.
InfoQ: As new JVM-based languages like Xtend are continually being introduced, how will these impact the success of Scala over time?
Martin: I do not want to speculate. A priori, movement and experimentation is a good thing. People who try out one language and like it tend to try out others as well.
InfoQ: As Java itself introduces features like modules and lambdas, will Java programmers wishing to add the functional paradigm simply stick with Java?
Martin: If it were that simple! Don't get me wrong: Closures are a welcome addition to Java. But to be functional you need to polish quite a few more rough edges. Languages such as Java are inherently oriented towards statements that change variables as side effects, whereas functional languages are oriented towards expressions. For example, try statements in Java can't return results, so every time you catch an exception in a try you need to change variables to have any effect at all. So I think closures in Java will support some functional idioms but wholesale adoption of the functional paradigm will still be painful.
InfoQ: Is there anything else you’d like to share with InfoQ readers?
Martin: I'm very excited about the next Scala Days conference, which will be April 16-17 in London. We expect 400 professionals to come to attend 37 talks. This will be an excellent opportunity to learn more about the great things happening in the community.
InfoQ: Thank you for spending time with us today and sharing your views with InfoQ readers.
Following up on Martin’s reference to Scala Days, InfoQ will be there conducting interviews and reporting on the conference. We are currently working on an arrangement to publish presentations from the event.
Finally, Typesafe expects to announce tomorrow its next version of Typesafe Stack 2.0. The stack features a comprehensive platform for building applications in Java and Scala that includes Play 2.0, a web framework that brings Rails–like productivity and ease of use to the JVM; Akka 2.0, an actor-based modern alternative to the J2EE for virtualized datacenters and clouds; and Typesafe Console, an enterprise-grade dashboard for monitoring and administering application built on the Typesafe Stack.
About the Interviewee
Martin Odersky is a co-founder of Typesafe, the creator of the Scala programming language, and a professor in the programming research group at EPFL, the leading technical university in Switzerland. Throughout his career, Martin's singular objective has been to make the basic job of writing programs faster, easier and more enjoyable. In the process he has personally written more lines of Java and Scala code than almost any other individual in the world. He wrote javac, the compiler used by the majority of today’s Java programmers, and scalac, the compiler used by the fast-growing Scala community. He authored "Programming in Scala," the best-selling book on Scala. Previously he has held positions at IBM Research, Yale University, University of Karlsruhe and University of South Australia, after having obtained his doctorate in 1989 from ETH Zürich as a student of Niklaus Wirth, the creator of Pascal.