One of the key goals of the Scala language is to combine the best object-oriented principles with the most useful features in functional programming. Scala's functional nature is very evident in the way Scala implements collections. While Scala's collections are on the surface similar to Java's, they add important, and very practical, features that can simplify a code base. In his latest installment of IBM developerWorks articles on Java, Ted Neward focuses on Scala's collection classes, The busy Java developer's guide to Scala: Collection types:

Scala's rich ... collections ... is a direct result of some of its functional history and feature set; tuples provide an easy way to gather a loosely bound set of values; Option[T] provides an easy way to indicate "some" value as opposed to "no" value in a straightforward way; arrays give access to traditional Java-style array semantics with some enhanced features; lists are the principal collection of functional languages, and so on...

Functional programming in Scala will give you some new design constructs and ideas, as well as built-in constructs that make programming certain scenarios (such as concurrency) much, much easier.

Neward first introduces the Scala Option type with an example:

[Imagine an] API designed to allow a caller to pass in a String containing the programmer's name, and it returns returns an Int, conveying the amount the programmer makes on a yearly basis; but there's the thorny problem of what to return in the event that the programmer isn't in the database. (Maybe she hasn't been hired, maybe she's been fired, maybe there's a typo in the name ...) If the return type is Int, then we can't return null, the usual "flag" indicating that the user wasn't found in the database...

[In Scala], instead of a method returning null to indicate that no data was found, the method is declared to return Option[T], where T is the original type returned. Then, in the scenarios where no data is found, simply return None.

Neward notes that Option can be imagined as a generic class with exactly two values, Some or None, and that Option works very well in conjunction with pattern matching:

Most of the time, when working with Option[T], programmers will use pattern matching, a highly functional concept that allows one to effectively "switch" on both types and/or values, not to mention bind values into variables at the point of definition, switch between Some and None, and extract the value out of Some...

Neward also discusses the concept of a tuple, which:

Are classes that simply collect a couple of other data types together into a single instance, with little to no attempt at encapsulation or abstraction — in fact, it is frequently more useful to not have any abstraction in place... Creating a tuple is a simple matter of putting the values inside a set of parentheses, almost as if they were inside a method call invocation. Extracting the values requires nothing more than invoking the "_n method, where n is the positional argument of the tuple element of interest...

Tuples make it trivial to carry multiple values around as a single entity, which means that tuples can offer something that would otherwise be extremely heavyweight to do in Java programming: multiple return values.

Even more interesting are Scala's array and list types, because they lend themselves to concise functional programming techniques, notes Neward:

In Scala, it's possible to use Array in the traditional sense, such as iterating using an Int from 0 to args.length - 1, and obtaining the i'th element of the array...

[But] Array has a large number of methods on it that it inherits from a surprisingly rich parent hierarchy: Array extends Array0, which extends ArrayLike[A], which extends Mutable[A], which extends RandomAccessSeq[A], which extends Seq[A], and so on, and so on, and so on. Naturally, all this parentage means that Array has a good many operations against it, making it easier to work with arrays in Scala when compared to Java programming.

The conclusion of Neward's article centers around lists:

A core feature of functional programming for years, lists have the same degree of "built-in"-ness that arrays have enjoyed for years in the object space... The list is like the array in that its core definition is a standard class from the Scala library, List[T]. And, like Array[T], List[T] inherits from a number of base classes and traits, starting with Seq[T] as an immediate base.

What do you think of Scala's collections from the point of view of expressiveness?