JavaOne 2010: A Brief Introduction to Scala

Steven Reynolds (a "software developer and manager" who works at INT) presented "A Brief Introduction to Scala" at JavaOne 2010. [As a side note, JavaFX Script is a casualty announced at JavaOne 2010, but JavaFX's use of SceneGraph seems stronger than ever and Reynolds has a presentation on that.] Reynolds asked who had heard of Scala and nearly everyone in the near-capacity room raised their hand.  However, when he followed up with who actually uses Scala, I could count the number of raised hands on the fingers of one of my hands.

Reynolds described Scala as "new-ish programming language for the JVM" that features a static type system and support for functional programming. In answering his own question in a slide titled, "Why Does Functional Programming Matter?" Reynolds (with tongue firmly in cheek) showed a direct correlation between Functional Programming and Google's $150 billion worth (MapReduce is the connection).

Scala's design goals include combining functional programming with object-oriented programming. Scala is also designed to be practical and interoperable with Java. The ability to call from Java to Scala and from Scala to Java allows Scala access to all SDK and other Java libraries. Scala designed to be powerful language that "trusts the programmer" and has a "powerful static type system that's easy to use." Reynold is "mystified" by people referring to Scala as a scripting language because of its powerful static typing. Frankly, I too think more of a dynamic language like Groovy for scripting than I do a static language like Java or Scala.

Reynolds provided a brief overview of characteristics of functional programming. In functional programming, functions are first class citizens. Functional programming has extreme immutability. Scala, because it's a "blended" language, does support mutability. The advantages of functional programming is that "what was once true is always true." In addition, "reasoning and testing are simpler." Reynolds also stated that Scala is "nice for concurrency and distributed systems." Reynolds' listed disadvantages of Scala were that "modular programming is sometimes harder" and there are "sometimes performance issues." Reynolds explained that these performance issues are sometimes attributable to the need to copy objects for immutability support.

Renyolds recommends the book Structure and Interpretation of Computer Programs. He stated, however, that you need to know Scheme to read this book.

Scala "gently guides you to use immutable code," but does support mutability. Reynolds talked about the difference between the Scala keywords val and var (val is for "unchanging value" and "var" is for "varying/variable value") when designating variables.

In Scala, every statement has a value. Reynolds contrasted this to Java where, for example, "if" statements don't really have values. Scala supports type referencing similar to Groovy's. I thought it was helpful to see the chart with a picture of a subset of Scala's type system. This visually made it clear that the Scala String and Double are not the same as equivalently named types in Java. It is interesting that the integer type in Scala is Int (capitalized like the Java reference type Integer, but with the same letters as the primitive 'int' type). Reynolds emphasized that the Scala types are more fully interconnected with each other in a lattice than are Java types (primitives are off on their own).

Reynolds showed an example from Scala's Predef that is available anywhere in Scala. He also talked about Scala's handy tuples. Reynolds's example created a tuple with simple parentheses-based syntax.

C++ supports multiple implementation inheritance (which is well known for the diamond problem) and Java intentionally only has single implementation inheritance. Scala goes in between: it is object-oriented with inheritance and objects and has single implementation inheritance with mixins (Traits).Scala's "with" keyword allows specification of the mixin/Trait.

Reynolds described how Scala-specific features like Traits can work when Scala is compiled to Java byte code. Scala compiles to .class files and be placed into a JAR just as in Java. Then, Reynolds suggested, use an IDE to open that JAR in a new project. He showed this with NetBeans 6.9. This gave insight into what this looks like "in a pure Java sense." Although Reynolds called it "under the hood and low level," I do like to use tactics like this to better understand "the magic." Reynolds also used Eclipse to see the byte code of this Scala-based JAR.

The Scala compiler (scalac) compiles Scala code into Java bytecode. Another good tip Reynolds provided is to use the scalac -Xprint:typer option to see what is generated. For someone with some Java experience and thinking about using Scala, these kinds of ideas (using the IDE to see Java equivalent or using the -Xprint:typer option with scalac) can help increase the comfort level in first using Scala.

Reynolds showed Scala's highly flexible case statement and I found it interesting that underscore (_) represents default case. It appears to me that, like Groovy, Scala's case needs to be carefully used because multiple options could "match" the condition (order does matter!).

Reynolds introduced Scala's well-known Actors and talked about how they help avoid shared mutable state. Messages are sent asynchronously. Reynolds briefly summarized inversion of control and stated that Scala had a design goal with Actors to enable event programming without inversion of control. This led to his explanation that react does not return. Benefits of Actors include no need to worry about "safe publication" and availability of explicit concurrency. Reynolds stated that even this nice approach to concurrency is not perfect.

I enjoyed Reynolds's presentation. It was exactly what I was looking for in an initial Scala overview. My only complaint was that this packed room got pretty warm in the afternoon. I normally don't have a lot of patience for that, but Reynolds's presentation was good enough to keep me there despite the uncomfortable temperature.

During the question and answer section, an attendee asked if JUnit could be used with Scala. Reynolds confirmed that JUnit can be used with Scala and referenced other Scala-specific testing framework ScalaTest as well. Another attendee asked about tooling for Scala. Reynolds acknowledged that Scala tooling has room for improvement. He stated that Scala is expected to have built-in features added that will help tooling for Scala.

Scala seems to be all the rage at this year's JavaOne. I appreciated Reynolds acknowledging that Scala might actually have a weakness or two. In Andres Almiray's presentation yesterday, he made an interesting comment during the question and answer section in which he sort of summarized on-the-fly that Scala may not be as strong as competitors in some areas (such as Groovy in metaprogramming or Clojure in concurrency), but that Scala does many things very well. If one is looking for a "general" language to cover broad needs, that's the kind of description you'd want.

Scala seems to be one of those things which has enthusiastic evangelists running around telling everyone how great it is without admitting many or significant drawbacks. I'm always leery of such one-sided things: they rarely (read never) are as flawless as advertised. However, I think Scala could be like Ruby was for me: it cannot possibly live up to the uber hype, but it really is nice when you get past the hype and look at it realistically. I try to not let unabated enthusiasm from well-meaning supporters distract me from rather a technology is useful to learn or not. I looked past this with Ruby and liked what I found and I could see the same happening for Scala. One of the types of sessions I like to attend at a conference are those that, within an hour or so, can help me decide if a particular subject is worth further investigation. This session did that for me: I saw enough here to believe that Scala may be worth some time investment.