Copyright © 2006 Penton Media, Inc., All rights reserved.
Printing of this document is for personal use only.
Reprints

Assembly language provides fine grain control. But it’s rarely used these days, with the exception of some operating-system hackers or 8-bit embedded programmers working on small modules. The performance of C compilers essentially blew the advantage out of the water ages ago. Yet in both cases, arbitrary memory access was the way to go.

This worked well with single-processor solutions, and it works reasonably well with symmetric and asymmetric shared-memory multiprocessors. Arbitrary access doesn’t work as well because there are more processors—maintaining coherency is critical to an application’s view of the world. It also is a difficult task, especially when dealing with multilevel caches.

Part of the problem is that most programming languages don’t adequately support immutable objects. The closest things in C are const definitions. Of course, strings, numbers, and the null value are all truly immutable in C and most other languages, and immutable objects are easy to replicate across a network of cores. While nothing comes for free, this immutability is one of several characteristics that can be exploited in a parallel-programming environment.

Unfortunately, such exploitation will be difficult with conventional languages because of their semantics. A number of languages, especially functional programming languages, are waiting in the wings to be the next great C# or Java replacement— or at least an alternative. One of these is called Scala.

SCALA’S ADVANTAGES
Scala is an interesting platform and a relatively new language. It runs on a Java virtual machine ( JVM) and incorporates ideas from a range of languages with concepts such as mixins and actors. Mixins, for those familiar with Lisp, are a way to address multiple inheritance. Immutable objects are also part of Scala’s repertoire.

Additionally, Scala is more refined for generics than Java. But the two can coexist, and Scala takes advantage of this relationship because of the underlying JVM. This did have some impact on how far Scala’s designers could take it, but it means the environment starts with a rich base. Support for .NET CLR is available as well with a corresponding base of support.

Scala’s actor and immutable object support really caught my eye. Actors utilize a message-passing communication architecture. This approach has been proven with operating systems like QNX and other languages such as Erlang. Scala actors are lightweight, making them fast. Also, they don’t share any state, preventing problems that arise from a sharedstate approach taken with Java and C#. And unlike active threads, Scala actors are event-driven.

Check out Scala’s embedded XML support. This is neat because its syntax is identical to XML, with the ability to embed Scala code within the data structure (see the figure). Most scripting languages like PHP can do this as well with strings. The difference is that Scala’s result is a real data structure that can be manipulated instead of a string that must be analyzed.

For more, take a look at Programming in Scala by the language’s designer, Martin Odersky. See ED Online 18173 at www.electronicdesign.com for my review of the book. Meanwhile, Scala isn’t the only platform designed to run on a JVM. Check out JRuby (a version of Ruby), Groovy, and Jython (a version of Python). Scala runs on Terracotta, a Java clustering system.

Chasing the next design approach like Scala obviously isn’t a great idea for production applications, unless you’re willing to live on the cutting edge. Still, that’s exactly what happened with C back when UNIX arrived on the scene.

In fact, design approaches like Scala have more stability and support than C or Java did when they started because of the JVM and Java support that Scala can call upon. Will Scala be the next Java or C#? Maybe. Maybe not. But how will you know if you don’t try it?