We’ve covered Scala more exhaustively than the other languages so far because Scala strongly supports two programming paradigms. The object-oriented features firmly position Scala as a Java alternative. Unlike Ruby and Io, Scala has a static typing strategy. Syntactically, Scala borrows many elements from Java, including curly braces and constructor usage.
Scala also offers strong support for functional concepts and immutable variables. The language has a strong focus on concurrency and XML, fitting a wide variety of enterprise applications currently implemented in the Java language.
Scala’s functional capabilities go beyond what I’ve covered in this chapter. I haven’t covered constructs such as currying, full closures, multiple parameter lists, or exception processing, but they are all worthy concepts that add to the power and flexibility of Scala.
Let’s look at some of Scala’s core strengths and weaknesses.
Most of Scala’s strengths are centered around an advanced programming paradigm that integrates well with the Java environment and some core well-designed features. In particular, actors, pattern matching, and the XML integration are important and well-designed. Let’s get right to the list.
Scala’s treatment of concurrency represents a significant advance in concurrent programming. The actor model and the thread pool are welcome improvements, and the ability to design applications without mutable state is absolutely huge.
The actor paradigm that you’ve seen in Io and now Scala is easy to understand for developers and well studied by the academic community. Both Java and Ruby could use some improvement in this area.
The concurrency model is only part of the story. When objects share state, you must strive for immutable values. Io and Scala get this at least partially right, allowing mutable state but also offering libraries and keywords that support immutability. Immutability is the single most important thing you can do to improve code design for concurrency.
Finally, the message-passing syntax you see in Scala is much like you will see in the next chapter on Erlang. It is a significant improvement over the standard Java threading libraries.
Scala starts with a strong, built-in user base: the Java community. Scala applications can use Java libraries directly, and through the use of code generation of proxy objects when necessary, the interoperability is excellent. Inferred typing is a much-needed advance over the archaic Java typing system. The best way to establish a new programming community is to fully embrace an existing one. Scala does a good job offering a more concise Java, and that idea has value.
Scala also offers new features to the Java community. Code blocks are a first-class language construct, and they work well with the core collection libraries. Scala also offers first-class mixins in the form of traits. Pattern matching is also a significant improvement. With these and other features, Java developers can have an advanced programming language without even touching the more advanced functional paradigms.
Throw in the functional constructs, and you can have significantly improved applications. Scala applications will usually have a fraction of the total lines of code than an equivalent Java app would have, and that’s extremely important. A better programming language should allow you to express more complex ideas with fewer lines of code, with minimal overhead. Scala delivers on this promise.
Scala’s flexible syntax and operator overloading make it an ideal language for developing Ruby-style domain-specific languages. Remember, as in Ruby, operators are simply method declarations, and you can override them in most cases. Additionally, optional spaces, periods, and semicolons let the syntax take many different forms. Together with robust mixins, these are the tools that a DSL developer seeks.
Scala has integrated XML support. The pattern matching makes parsing blocks of disparate XML structures easy to use. The integration of the XPath syntax for diving deep into complex XML leads to simple and readable code. This advance is welcome and important, especially to the XML-heavy Java community.
The emergence of each new programming paradigm needs a bridge. Scala is well-positioned to be that bridge. The functional programming model is important because it handles concurrency well, and evolving processor designs are much more concurrent. Scala offers an iterative way to take developers there.
Although I like many of the Scala ideas in concept, I find the syntax demanding and academic. Although syntax is a matter of taste, Scala does have a higher burden than most other languages, at least to these old eyes. I also recognize that some of the compromises that make Scala such an effective bridge also will undercut its value. I only see three weaknesses, but they are big ones.
Static typing is a natural fit for functional programming languages, but Java-style static typing for object-oriented systems is a deal with the devil. Sometimes, you must satisfy a compiler’s requirements by putting more of a burden on your developers. With static typing, the burden is much more than you ever expect. The impact on code, syntax, and program design are profound. As I learned Scala, I found myself in a fairly constant battle with the language syntax and in program design. Traits eased this burden somewhat, but I found the trade-off between programmer flexibility and compile-time checking wanting.
Later in this book, you’ll see what a purely functional strong, static type system looks like with Haskell. Without the burden of two programming paradigms, the type system becomes much more fluid and productive, providing better support for polymorphism and requiring less rigor from programmers for similar benefit.
I do find Scala’s syntax to be a little academic and hard on the eyes. I hesitate to put this in print because syntax can be so subjective, but some elements are a little baffling. Sometimes, Scala keeps Java conventions, such as constructors. You’d use new Person rather than Person.new. At other times, Scala introduces a new convention, as with argument types. In Java, you’d use setName(String name) versus Scala’s setName(name: String). Return types shift to the end of the method declaration versus the beginning, as they are with Java. These little differences keep me thinking about syntax rather than code. The problem is that moving back and forth between Scala and Java will take more effort than it should.
When you build a bridge language, you must factor in compromises. One significant compromise in Scala is the introduction of mutability. With var, Scala opens Pandora’s box in some ways, because the mutable state allows a wide variety of concurrency bugs. But such compromises are unavoidable if you want to bring home the special kid who lived in the house on the hill.
All in all, my experience with Scala was mixed. The static typing threw me. At the same time, the Java developer in me greatly appreciates the improved concurrency models, inferred typing, and XML. Scala represents a significant jump in the state of the art.
I would use Scala to improve my productivity if I had a significant investment in Java programs or programmers. I’d also consider Scala for an application that has significant scalability requirements that would require concurrency. Commercially, this Frankenstein has a good shot because it represents a bridge and fully embraces a significant programming community.
| [10] |
Edward Scissorhands. DVD. Directed by Tim Burton. 1990; Beverly Hills, CA: 20th Century Fox, 2002. |
| [11] |
Use & beginning in Scala 2.8.0, because ** is deprecated. |
| [12] |
In version 2.8.0, |
| [13] |
In version 2.8.0, |
| [14] |
In version 2.8.0, |