Home Scala: Java Scaled Up

Scala: Java Scaled Up

The inherent problem with procedural programming languages is that they’re not designed for parallel processing. A common language’s typical approach to multithreading is to bolt on an asynchronous library, and have developers use it to write individual callback functions that may run concurrently and signal back when they’re done. You might have a few asynchronous functions going at once, but you’re still invoking them in sequence.

A language that embraced asynchronicity and parallelism at its core would have to adopt a very different mindset. But what if a language adopted a broader syntax that incorporated the older, synchronous procedural model word-for-word, but enabled the developer to transition to asynchronicity at her own pace… and for Android developers, produced the same bytecode that Android’s Dalvik interpreter expects? Would you believe one Java engineer already had the answer back in 2003?

Prof. Martin Odersky of the Swiss Federal Institute of Technology at Lausanne (EFPL) is actually a Java master. Today, he’s the Chairman and Chief Architect of Typesafe, the consultancy which produces the commercial rendition of Scala. In 1998, Odersky renovated and rewrote the old Java reference compiler, into the javac used ever since JDK 1.5 (the current release is JDK 7u1). Five years later, he led the successful effort to introduce a C++ concept to Java called generics, enabling functions to specify their argument types so that errors may be trapped at compile time rather than caught at runtime.

About a decade ago, Odersky and his colleagues were working on a project then called Pizza, as an experimental scalable language — a test of the notion that a scripting language can be extended into a fully functional (in the algebraic sense), object-oriented language without losing its utility in scripting. In other words, what Java should be.

From Pizza to pi

“I came from Java, and wanted to do something that would take better advantage both of new hardware and a higher mode of thinking about programs,” Odersky tells RWW. “We wanted to mix into the object-oriented framework that you have in Java, and also in Scala, these ideals from functional programming. Scala is essentially a fusion of the old object-oriented and the new functional.”

To understand what he means, you need to refrain from thinking of the term “functional” as synonymous with “working.” Of course, it’s going to work; but to make the most of Scala (pronounced “scah – la,” to rhyme with “Java”), a developer should embrace the notion that a function (a component of code, which in Scala is fully reusable) is both an object (a structure with methods, properties, and defined characteristics) and a function (a mathematical structure that reduces to a value).

The professor explains: “In the classical mode of programming, you have a bunch of variables. When you go object-oriented, those variables will be fields of your objects, and your program is moreover about changing the values of these variables while you program. That means it’s very slow; you think in terms of sequence of actions. ‘To change this variable, I have to do that, and then the other thing, and this variable must be set to that value before I can do this other thing.’ Functional programming is different; it tries to have very little of that, ideally nothing at all (though we don’t reach the ideal all the time). The idea is more that we produce new things out of old things. So from these artifacts that I have, which are data structures, I produce new data structures. Then the old ones will eventually be recycled by your garbage collector because nobody needs them anymore.”

The pros and cons of immutability

Variables in everyday programming tend to be used as registers, representing whether an event has occurred or a function has done its job properly. Back in the old BASIC days, I called them “flag variables.” You poll the flag variable, and if it comes back True, you’re in good shape and you can proceed. Odersky explains this mode of programming as representing state, or what others might call “status.” So a huge chunk of the developer’s job is spent doing what he calls “state mutation.”

Odersky designed Scala to eliminate the need for all state mutation. In fact, a full-scale, static-typed Scala-style object (which is calls “idiomatic code,” exorcising all hint of Java-ness) has no mutable fields or variables whatsoever. While ordinary Java-style variables are declared using the familiar var keyword, Scala-style immutable ones are declared with val — which you might not notice until you look really closely. “They get assigned on construction, and they don’t get changed any more after that,” he says. You want an object whose variables have different states, you instantiate a new object.

Here’s an example from Cay Horstmann’s Addison-Wesley e-book, distributed by Typesafe, entitled Scala for the Impatient. It has familiar phraseology for the Java veteran: It’s a simplified example of a class that represents a bank account. Its members are an immutable variable, a standard variable set to an integer (Scala variables are never “variants”), and a member method that’s completely explained inline:

class Account {

val id = Account.newUniqueNumber()

private var balance = 0.0

public def deposit(amount: Double) { balance += amount }

...

}

Just how is immutability supposed to help anyone? If you shave down your concept of an object to a function that evaluates inputs and produces an output, you eliminate sequential-ness from the bytecode that the compiler produces, enabling more threads that can be run simultaneously. The tradeoff is that it leaves a big mess behind. Scala does not come with its own garbage collector, so the developer must rely on the memory management and garbage collecting facilities of the environment it’s running in. The professor says Android has a better garbage collector than the type you’d find with Python, Ruby, or PHP.

“Scala is a very pragmatic language, in the sense that it makes it easy for you to use this functional stuff, but it doesn’t make it any harder for you to use the old imperative stuff,” he tells us. Scala won’t discourage Java developers from continuing to use the older “imperative” model, and you certainly don’t suffer a performance hit for doing so.

The current version of the Scala development environment for all platforms, including Unix, Mac OS X, and Windows is available from Scala’s download page. Earlier this month, Typesafe announced Scala’s availability for deployment on the Heroku cloud platform, and we’ll talk more about that, plus the network-ready, event-driven middleware layer for Scala called Akka, later on RWW.

About ReadWrite’s Editorial Process

The ReadWrite Editorial policy involves closely monitoring the tech industry for major developments, new product launches, AI breakthroughs, video game releases and other newsworthy events. Editors assign relevant stories to staff writers or freelance contributors with expertise in each particular topic area. Before publication, articles go through a rigorous round of editing for accuracy, clarity, and to ensure adherence to ReadWrite's style guidelines.

Get the biggest tech headlines of the day delivered to your inbox

    By signing up, you agree to our Terms and Privacy Policy. Unsubscribe anytime.

    Tech News

    Explore the latest in tech with our Tech News. We cut through the noise for concise, relevant updates, keeping you informed about the rapidly evolving tech landscape with curated content that separates signal from noise.

    In-Depth Tech Stories

    Explore tech impact in In-Depth Stories. Narrative data journalism offers comprehensive analyses, revealing stories behind data. Understand industry trends for a deeper perspective on tech's intricate relationships with society.

    Expert Reviews

    Empower decisions with Expert Reviews, merging industry expertise and insightful analysis. Delve into tech intricacies, get the best deals, and stay ahead with our trustworthy guide to navigating the ever-changing tech market.