Summary
Ted Neward recently started a new column dedicated to Scala on IBM's developerWorks site. The inaugural article introduces some of the functional programming features of Scala to a busy Java programmer, showing how first-class functions can solve real-world programming problems.
Advertisement
Scala has been getting a lot of attention lately, in part because of its fit in the Java ecosystem, and because of the elegant solutions Scala provides to some of the limitations in the Java language. Ted Neward started a new column on IBM developerWorks, titled The Busy Java Developer's Guide to Scala.
In the first installment, Functional programming for the object oriented, Neward explains the need for a language that works well both in a highly concurrent environment and also in the Java ecosystem:
The critical flaw is the fact that most of these languages [that aim to work well in a concurrent environment] were built on top of their own virtual machine or interpreter, so they represent (like Ruby does) a transition to a new platform. The concurrency crunch is a real concern, and some of the new languages offer powerful answers, but too many corporations and enterprises remember migrating from C++ to the Java platform just 10 years ago. To move to a new platform is a risk that many companies just aren't going to seriously consider. Many, in fact, are still nursing the scars from the last move to the Java platform.
Neward lists three Scala attributes that should make it a compelling language for any Java developer to learn:
First, Scala compiles to Java bytecode, meaning it runs on the JVM. In addition to enabling you to continue leveraging the rich Java open-source ecosystem, Scala can be integrated into an existing IT environment with zero migration effort.
Second, Scala is based on the functional principles of Haskell and ML, yet still borrows heavily from the familiar object-oriented concepts Java programmers love. As a result, it can blend the best of both worlds into a whole that offers significant benefit without sacrificing the familiarity we've come to depend on.
Finally, Scala was developed by Martin Odersky, probably best known in the Java community for the Pizza and GJ languages, the latter of which became the working prototype for Java 5's generics. As such, it comes with a feeling of "seriousness"; this language was not created on a whim, and it will not be abandoned in the same fashion.
The rest of Neward's article gives a taste of functional programming to the Java developer:
Functional languages get their name from the concept that programs should behave like mathematical functions; in other words, given a set of inputs, a function should always return the same output. Not only does this mean that every function must return a value, but that functions must inherently carry no intrinsic state from one call to the next. This intrinsic notion of statelessness, carried over into the functional/object world to mean immutable objects by default, is a large part of why functional languages are being hailed as the great saviors of a madly concurrent world...
Numerous other functional features (such as pattern matching) have made their way into the Scala language... Scala also adds in a number of features currently missing in Java programming, such as operator overloading (which, it turns out, isn't at all like how most Java developers imagine it), generics with "upper and lower type bounds," views, and more. These features, among others, make Scala extremely powerful for handling certain tasks, such as processing or generating XML.
Neward illustrates Scala's ability to work with first-class functions with an example that would be much more complex to write in Java:
This is a common theme in functional languages: create a high-level abstract function that does one thing, let it take a block of code (an anonymous function) as a parameter, and call that block of code from within the high-level function. Take walking across a collection of objects, for example. Rather than using the traditional Java iterator object inside of a for loop, a functional library will instead define a function — usually called "iter" or "map" — on the collection class that takes a function taking a single parameter (the object being iterated over).
As Neward points out, functional programming languages have been around for a long time, but haven't really become a mainstay of enterprise software development. To what extent do you think Scala, and other modern functional languages, such as F#, will make functional programming concepts more accepted in the enterprise?
I think that yes. This is not really directly related, but the three letter company has already customer(s) that has Groovy scripts for some tasks on servers.
> I think that yes. This is not really directly related, but > the three letter company has already customer(s) that has > Groovy scripts for some tasks on servers.
I would expect that a computing company the size of IBM has customers that implement pretty much any computing technology that you can name.
Sure, but it's quite different with new techs. There's more marketing in it, since you have to literally talk the client in to switch to new tech. Upgrades costs money and the golden rule of service delivery (never touch running system) makes it even harder.