JavaOne 2012: What’s New in Scala 2.10

After getting lunch, I went to Hilton Golden Gate 6/7/8 to see Martin Odersky's (Typesafe) presentation "What’s New in Scala 2.10." It is always an opportunity to hear a language's creator discuss the language that he created.

Odersky stated by providing a brief history of Scala:

1996-1997	Pizza
1998-2000	GJ, Java generics, javac
2003-2006	The Scala "Experiment"
2006-2009	Industrial Strength Programming Language

Scala is a unifier between worlds of functional programm and object-oriented programming and is a unifier of agile (with lightweight syntax) and safe/performant/strongly typed programming.

Functional programming on the rise. 12 years ago OOPSLA had ten times attendance of ECOOP but today ICFP has three times ECOOP attendance and OOPSLA is no longer an independent conference. Functional programming important now because of market drivers. Odersky stated, "The world of software is changing because of hardware trends" and added, "Moore's Law is now achieved by increasing number of cores rather than clock cycles."

In this new world of clock cycle limitations, we have a "Triple Challenge": "Parallel" (how to use multicore), "Asynchronous" (how to deal with asynchronous events), and "Distributed" (how to deal with failures). In this world, "every piece of mutable state you have is a liability." The "problem in a nutshell" is "non-determinism caused by concurrent threads accessing shared mutable state."

non-determinism = parallel processing + mutable state

Non-deterministic behavior is something "we are uncomfortable with" and "avoiding mutable state means programming functionally." Eliminating mutable state is the one thing we have control over and can change. This is why Odersky believes that functional programming is just now rising out of the academic world to be used in the business world. Functional programming has always been inherently tied to fancy machines.

Odersky pointed out that writing functional programming is quite different than writing object-oriented programming. The "thought process of functional programming is really quite different" because it requires thinking of things spatially rather than temporally.

Having made the case for functional programming, Odersky asked if we should all move to Haskell now? He answered that there are still important things learned from object-oriented development. His slide stated, "What the industry learned about OO decompositionis analysis and design stays valid." We want to have functions and objects in our coding.

Odersky quoted Grady Booch, "Objects are characterized by state, identity, and behavior. Odersky maintains we now want to "eliminate, or at least reduce, mutable state." We want to get away from mutable state being the default. Odersky also believes we want to get away from referential equality and focus on structural equality.

Odersky listed simplicity, productivity, and fun as other reasons for functional programming in addition to dealing with the hardware environment of parallel processors.

Odersky moved from general functional programming discussion to specific Scala discussion. His bullet stated, "Scala can be as simple or as complex as you like, but it's best when it's simple." He cited Kojo as an example of Scala's alignment with simplicity. He also referenced "Sadaj's great talks." Odersky then began to work on some examples based on Ninety-Nine Scala Problems.

Scala 2.10 is "very close to RC1" and is in "code freeze" while working on three remaining code blockers and several documentation blockers. Odersky talked about the Scala Improvement Process (SIP) and showed the "Pending SIPs" that are accepted, postponed, or rejected.

SIP 12 ("String Interpolation" addresses the weaknesses and difficulties associated with concatenation of Strings using the + operator. It is shorter and safer to use string interpolation. The biggest obstacle to adding string interpolation was that $ is "already a legal character in strings." Rather than using a "special trick" of placing "s" in front of strings for which $ should be escaped and used for string interpolation, Scala will use more general solution of recognizing arbitrary IDs. The "f" string processor will interpret $ and %.

Developers could implement their own string processors and Odersky showed examples of this that might be written for XML and JSON. Odersky stated that, "Adding XML support in Scala is something that did not turn out so well." He says now there would be an advantage to using an XML string processor instead and remove the XML specific library dependency Scala currently has.

Odersky addressed why Scala does not have extension methods that "other cool languages" have. He answered that Scala does not have extension methods because "we can't abstract over them." It is "impossible to have them implement an interface."

Odersky introduced SIP 11 ("Implicit Classes"). One issue to think about here is "runtime overhead." SIP 15 ("Value Classes") introduces idea that Scala classes could extend AnyVal instead of Object. Classes extending AnyVal are "value classes" and are always unboxed. Odersky showed what code using these value classes would expand (be compiled) to.

The implicit keyword in Scala enables "very poweful" implicit conversions, but Odersky warns that "they can be misused" particularly if "there are too many of them." I like that Odersky likened them to chocolate: a little is very good, but too much leads to a stomach ache. You can turn off implicit conversion warnings by "bringing the identifier scala.langage.implicitConversions into scope (typically via import).

Odersky briefly discussed SIP 18 ("Language Imports") and then covered "Better tools." I found Odersky's goal for his language to be interesting: Odersky wants to "make Scala the language of choice for smart kids." To him, it's the ideal of what the language should be.

One attendee felt that boilerplate code is one of the best forms of simplicity and wondered whether Scala was missing its goal of simplicity by displacing boilerplate code. Odersky replied that boilerplate code would not be his preferred form of simplicity.

Odersky stated that Scala is largely mature from the perspective of significant API changes and so forth. He pointed out that all languages reach the point where it is difficult to make wholesale fundamental changes and that Scala's changes are smaller in nature now than they were in the late 2000s.

In response to an audience member's question, Odersky said that the best way to learn Scala is to read a book or take a course. He says many of the people he sees who try and struggle with Scala tried to learn it by studying its API documentation.

When asked to compare Scala to Groovy and JRuby, Odersky said that Scala is about as complicated as JDK 7 and will be less complicated than JDK 8. He feels Groovy is more complicated because it is a superset of Java. This is an interestingly different perspective on complexity. I have found Groovy to be very simple to learn, but I do have years of Java experience. I wonder if someone without Java experience would find Scala less difficult to learn. For me, even with all of Scala's great features, it cannot be easier to learn than Groovy was.

Another audience member's question led to Odersky mentioning some alternate IDE support (including Emacs and IntelliJ IDEA) for Scala in addition to ScalaIDE. There is a NetBeans plugin for Scala.

Odersky pointed out something I like about Scala in response to another question. He stated that Scala allows the developer to easily specify a piece of data is mutable. I like that Scala "does not prejudice" against mutable data and allows the developers to choose to do so if they want to. I really don't like it when "opinionated software" forces me to do what the framework's or language's author thinks is best.

I really enjoyed this presentation. I had changed from a differently planned session to this one last night and am happy with the change (although the other likely would have been good as well). My only concern about this presentation had been that, given my lack of Scala familiarity, that I'd be overwhelmed by discussion of new Scala 2.10 features without proper foundation. Fortunately for me, Odersky did not get into Scala 2.10-specific features until half way into the session. His coverage of functional programming and basics and history of Scala were helpful to me in general and were helpful specifically in preparing me to appreciate the new Scala 2.10 features. Between this presentation and the Scala Tricks presentation, my interest in trying out Scala is being renewed.

The photograph in this post was taken at Muir Woods National Monument before the beginning of JavaOne 2012.