I'm at the Scala lift-off today in San Francisco, an unconference organized by Dave Pollak, author of the lift web framework and frequent hanger-out at the Twitter office (or Twoffice if you will).
Martin Odersky, author of the Scala programming language, is kicking off the day. Martin teaches at EPFL in Switzerland, and has a background in functional languages. Before Scala, he's had a hand in several functional languages on the JVM, as well as rewriting the Java compiler for performance and correctness. The Scala effort started in 2002, but the community has really been growing since 2006 when a redesigned implementation of the language was released. This week has seen quite a bit of Scala buzz at JavaOne, including an endorsement of Scala as the premier alternative JVM language by Java author James Gosling.
Odersky opens with an argument for a scalable language: one that's suitable for small and large programs, from parsing to scripting, from extension scripts to heavy lifting libraries, one that embraces Domain-Specific Languages (DSLs) rather than a reliance on external languages.
In one sense, Odersky suggests, Scala is a scripting language. It's possible to simply type code into an interpreter and have it evaluated. There can be very little boilerplate code in Scala, and most types can be inferred.
In another sense, Scala is the "Java of the future." Scala boasts most every language feature Java currently has, and many that are still pending or under debate in the Java community, such as closures, traits, and pattern matching. Scala complies down to .class files, and Odersky jokes that he should know, given that he's written two versions of the shipping Sun Java compiler. Scala's performance and operational profile is thus the same as Java's, give or take special cases and the use of alternative libraries.
In still another sense, Scala is a "composition language", one with a new approach to modular systems. In Scala, components are classes or traits that can be composed via mixins. Abstraction is accomplished through abstract members, parameters, or self types; essentially, both functional and OOP metaphors for abstraction are available.
For all that, Scala is trying to avoid becoming a "kitchen-sink language". Scala is comparable in feature count to Java, but has far fewer features than C++ or C#. Scala removes the following from the Java feature set: static members, primitive types, break, continue, special treatment of interfaces, wildcards, raw types, and enums. Scala "concentrates on the glue", not on features. Leveraging abstraction, users can implement the features they need in the language, rather than the language itself supporting every possible use case. The same set of constructs are intended to support both small and large programs.
Scala's lightweight syntax comes from a number of features: semicolon inference, type inference, lightweight classes, extensible APIs, and closures as control abstractions. On average, Odersky predicts a 2x reduction in lines of code between a Java program and a Scala port.
Odersky suggests that "scalability demands extensibility." As an example, he notes all the different data types traditionally used for numerics in programming languages: int, long, float, double, complex, rational, interval, polynomial, etc. While a language could support every possible numeric data type, Scala's extensibility strategy encourages abstractions and additions to existing types and methods to provide new numeric data types seamlessly. For example, it's possible to define + and - methods, essential to dropping in YourFancyNumeric class without pain.
As another example of Scala's extensibility, Oderksy demonstrates adding new control structures. A using method executes a block of operations on a resource, then closes that resource. It's a simple pattern with a short implementation, but the terse code is expressive and requires intimate understanding of Scala's type system to understand what's going on.
Scala makes its scalability claims on the tight integration of functional and object-oriented programming. One of the important concepts here is that functions themselves are objects in Scala. Additionally, Scala offers Erlang-style Actors for high-concurrency programs, contributing to "scalability" in the operational/performance sense.
Like Erlang, Scala provides Actors with mailboxes for messages passed to them. Conventionally, a programmer has her Actors process received messages with a pattern match. Odersky notes that the Actor features of Scala are libraries, not core language features, and argues that this is a testament to the strength of libraries and an extensible approach to language design. Actors in Scala are implemented atop the FJ Framework; the event-driven flavor of Actors (using react) scale up to hundreds of thousands of processes in tests.
The next problem to be solved for Scala is maintaining expressiveness while keeping programs safe and verifiable. A project on "pluggable type systems" is underway, but is unlikely to yield changes to Scala for several years.
Odersky notes a number of companies working in Scala: Google, Buy-a-Feature, Gump-It, Joberator, EDP Training, Reaktor Innovations, Sygneca. Scala tools are improving, from the language's own complier, background complier, and interactive shell to testing frameworks and plugins for all the major Java IDEs. Rounding out, the "official" Scala book will be coming out soon.
Question time!
Are Scala classes open? No, because that defeats static typing. But: mixins, etc.Does calling into Scala code from Java necessitate reflection? [Answer not captured, sorry.]
How stable is the language and what's the path for future features? We've agreed to slow the development of the language. There will be a standard distribution and an experimental branch.
Is there a project to add Scala support to the Java compiler so you can mix the two languages in the same project/file? Yes! Eclipse has this working to some degree, other projects are underway.
Because of the unconference format, more questions will be asked of Martin throughout the day and the Q&A session was cut short.
