Scala (programming language)

Scala

Paradigm(s)	Multi-paradigm: functional, object-oriented, imperative, concurrent
Appeared in	2003
Designed by	Martin Odersky
Developer	Programming Methods Laboratory of École Polytechnique Fédérale de Lausanne
Stable release	2.10.1 (March 13, 2013 (2013-03-13)[1])
Preview release	2.11.0-M2 (March 14, 2013 (2013-03-14)[2])
Typing discipline	static, strong, inferred, structural
Influenced by	Eiffel, Erlang, Haskell,[3] Java, Lisp,[4] Pizza,[5] Standard ML, OCaml, Scheme, Smalltalk
Influenced	Fantom, Ceylon, Kotlin
Platform	JVM, CLR, LLVM
License	BSD
Usual filename extensions	.scala
www.scala-lang.org Scala at Wikibooks

Scala (pron.: /ˈskɑːlə/ SKAH-lə) is an object-functional programming and scripting language for general software applications, statically typed, designed to concisely express solutions in an elegant,^[6] type-safe and lightweight manner. Scala includes full support for functional programming (including currying, pattern matching, algebraic data types, lazy evaluation, tail recursion, immutability, etc.). It cleans up what are often considered to have been poor design decisions in Java (e.g. type erasure, checked exceptions, the non-unified type system) and adding a number of other features designed to allow cleaner, more concise and more expressive code to be written.^[5]

It is intended to be compiled to Java bytecode (the executable JVM ) or .NET. Both platforms are officially supported by the EPFL. Like Java, Scala is statically typed and object-oriented, uses a curly-brace syntax reminiscent of C, and compiles code into Java bytecode, allowing Scala code to be run on the JVM and permitting Java libraries to be freely called from Scala (and vice-versa) without the need for a glue layer in-between. Compared with Java, Scala adds many features of functional programming languages like Scheme, Standard ML and Haskell, including anonymous functions, type inference, list comprehensions (known in Scala as "for-comprehensions"), lazy initialization, extensive language and library support for side-effect-less code, pattern matching, case classes, delimited continuations, higher-order types, much better support for covariance and contravariance than in Java, etc. Scala also provides a unified type system (as in C#, but unlike in Java), where all types, including primitive types like integers and booleans, are objects that are subclasses of the type Any. Scala likewise contains a number of other features present in C# but not Java, including operator overloading, optional parameters, named parameters, raw strings (that may be multi-line in Scala), and no checked exceptions.

The name Scala is a blend of "scalable" and "language", signifying that it is designed to grow with the demands of its users. James Strachan, the creator of Groovy, described Scala as a possible successor to Java.^[7]

History [edit]

The design of Scala started in 2001 at the École Polytechnique Fédérale de Lausanne (EPFL) by Martin Odersky, following on from work on Funnel, a programming language combining ideas from functional programming and Petri nets.^[8] Odersky had previously worked on Generic Java and javac, Sun's Java compiler.^[8]

Scala was released late 2003/early 2004 on the Java platform, and on the .NET platform in June 2004.^[5][8][9] A second version of the language, v2.0, was released in March 2006.^[5]

On 17 January 2011 the Scala team won a five year research grant of over €2.3 million from the European Research Council.^[10] On 12 May 2011, Odersky and collaborators launched Typesafe Inc., a company to provide commercial support, training, and services for Scala. Typesafe received a $3 million investment from Greylock Partners.^{[11][12][13][14]}

Platforms and license [edit]

Scala runs on the Java platform (Java Virtual Machine) and is compatible with existing Java programs. It also runs on Android smartphones.^[15] An alternative implementation exists for the .NET platform.^[16][17]

The Scala software distribution, including compiler and libraries, is released under a BSD license.^[18]

Examples [edit]

"Hello World" example [edit]

Here is the classic Hello World program written in Scala:

 object HelloWorld extends App {
   println("Hello, World!")
 }

Unlike the stand-alone Hello World application for Java, there is no class declaration and nothing is declared to be static; a singleton object created with the object keyword is used instead.

With the program saved in a file named HelloWorld.scala, it can be compiled from the command line:

$ scalac HelloWorld.scala

To run it:

$ scala HelloWorld

This is analogous to the process for compiling and running Java code. Indeed, Scala's compilation and execution model is identical to that of Java, making it compatible with Java build tools such as Ant.

A shorter version of the "Hello World" Scala program is:

println("Hello, World!")

Saved in a file named HelloWorld2.scala, this can be run as a script without prior compilation using:

$ scala HelloWorld2.scala

Commands can also be fed directly into the Scala interpreter, using the option -e:

$ scala -e 'println("Hello, World!")'

A basic example [edit]

The following example shows the differences between Java and Scala syntax:

// Java:
int mathFunction(int num) {
    int numSquare = num*num;
    return (int) (Math.cbrt(numSquare) +
      Math.log(numSquare));
}

// Scala: Direct conversion from Java
 
// no import needed; scala.math
// already imported as `math`
def mathFunction(num: Int): Int = {
  var numSquare: Int = num*num
  return (math.cbrt(numSquare) + math.log(numSquare)).
    asInstanceOf[Int]
}

// Scala: More idiomatic
// Uses type inference, omits `return` statement,
// uses `toInt()` method, normally called without parens
 
import math._
def intRoot23(num: Int) = {
  val numSquare = num*num
  (cbrt(numSquare) + log(numSquare)).toInt
}

Note in particular the syntactic differences shown by this code:

1. Scala does not require semicolons.
2. Value types are capitalized: Int, Double, Boolean instead of int, double, boolean.
3. Parameter and return types follow, as in Pascal and C++11, rather than precede.
4. Functions must be preceded by def.
5. Local or class variables must be preceded by val (indicates an unmodifiable variable) or var (indicates a modifiable variable).
6. The return operator is unnecessary in a function (although allowed); the value of the last executed statement or expression is normally the function's value.
7. Instead of the Java cast operator (Type) foo, Scala uses foo.asInstanceOf[Type], or a specialized function such as toDouble or toInt.
8. Instead of Java's import foo.*;, Scala uses import foo._.
9. Function or method foo() can also be called as just foo; method thread.send(signo) can also be called as just thread send signo; and method foo.toString() can also be called as just foo toString.

(These syntactic relaxations are designed to allow support for domain-specific languages.)

Some other basic syntactic differences:

1. Array references are written like function calls, e.g. array(i) rather than array[i]. (Internally in Scala, both arrays and functions are conceptualized as kinds of mathematical mappings from one object to another.)
2. Generic types are written as e.g. List[String] rather than Java's List<String>.
3. Instead of the pseudo-type void, Scala has the actual singleton class Unit (see below).

An example with classes [edit]

The following example contrasts Java and Scala ways of defining classes.

// Java:
public class Point {
  private double x, y;
 
  public Point(final double X, final double Y) {
    x = X;
    y = Y;
  }
 
  public double x() {
    return x;
  }
 
  public double y() {
    return y;
  }
 
  public Point(
    final double X, final double Y,
    final boolean ADD2GRID
  ) {
    this(X, Y);
 
    if (ADD2GRID)
      grid.add(this);
  }
 
  public Point() {
    this(0.0, 0.0);
  }
 
  double distanceToPoint(final Point OTHER) {
    return distanceBetweenPoints(x, y,
      OTHER.x, OTHER.y);
  }
 
  private static Grid grid = new Grid();
 
  static double distanceBetweenPoints(
      final double X1, final double Y1,
      final double X2, final double Y2
  ) {
    double xDist = X1 - X2;
    double yDist = Y1 - Y2;
    return Math.sqrt(xDist*xDist + yDist*yDist);
  }
}

// Scala
class Point(
    // adding `val` here automatically creates
    // public accessor methods named `x` and `y`
    val x: Double, val y: Double,
    addToGrid: Boolean = false
) {
  // import functions/vars from companion object
  import Point._
 
  if (addToGrid)
    grid.add(this)
 
  def this() {
    this(0.0, 0.0)
  }
 
  def distanceToPoint(other: Point) =
    distanceBetweenPoints(x, y, other.x, other.y)
}
 
object Point {
  // private/protected members shared between
  // class and companion object
  private val grid = new Grid()
 
  def distanceBetweenPoints(x1: Double, y1: Double,
      x2: Double, y2: Double) = {
    val xDist = x1 - x2
    val yDist = y1 - y2
    math.sqrt(xDist*xDist + yDist*yDist)
  }
}

The above code shows some of the conceptual differences between Java and Scala's handling of classes:

1. Scala has no static variables or methods. Instead, it has singleton objects, which are essentially classes with only one object in the class. Singleton objects are declared using object instead of class. It is common to place static variables and methods in a singleton object with the same name as the class name, which is then known as a companion object. (The underlying class for the singleton object has a $ appended. Hence, for class Foo with companion object object Foo, under the hood there's a class Foo$ containing the companion object's code, and a single object of this class is created, using the singleton pattern.)
2. In place of constructor parameters, Scala has class parameters, which are placed on the class itself, similar to parameters to a function. When declared with a val or var modifier, fields are also defined with the same name, and automatically initialized from the class parameters. (Under the hood, external access to public fields always goes through accessor (getter) and mutator (setter) methods, which are automatically created. The accessor function has the same name as the field, which is why it's unnecessary in the above example to explicitly declare accessor methods.) Note that alternative constructors can also be declared, as in Java. Code that would go into the default constructor (other than initializing the member variables) goes directly at class level.
3. Default visibility in Scala is public.

Features (with reference to Java) [edit]

Scala has the same compilation model as Java and C# (separate compilation, dynamic class loading), so Scala code can call Java libraries (or .NET libraries in the .NET implementation).

Scala's operational characteristics are the same as Java's. The Scala compiler generates byte code that is nearly identical to that generated by the Java compiler. In fact, Scala code can be decompiled to readable Java code, with the exception of certain constructor operations. To the JVM, Scala code and Java code are indistinguishable. The only difference is a single extra runtime library, scala-library.jar.^[19]

Scala adds a large number of features compared with Java, and has some fundamental differences in its underlying model of expressions and types, which make the language theoretically cleaner and eliminate a number of "corner cases" in Java. From the Scala perspective, this is practically important because a number of additional features in Scala are also available in C#. Examples include:

Syntactic flexibility [edit]

As mentioned above, Scala has a good deal of syntactic flexibility, compared with Java. The following are some examples:

1. Semicolons are unnecessary; lines are automatically joined if they begin or end with a token that cannot normally come in this position, or if there are unclosed parentheses or brackets.
2. Any method can be used as an infix operator, e.g. "%d apples".format(num) and "%d apples" format num are equivalent. In fact, arithmetic operators like + and << are treated just like any other methods, since function names are allowed to consist of sequences of arbitrary symbols (with a few exceptions made for things like parens, brackets and braces that must be handled specially); the only special treatment that such symbol-named methods undergo concerns the handling of precedence.
3. The final () can be left off of a function that takes no arguments.

By themselves, these may seem like questionable choices, but collectively they serve the purpose of allowing domain-specific languages to be defined in Scala without needing to extend the compiler. For example, Erlang's special syntax for sending a message to an actor, i.e. actor ! message can be (and is) implemented in a Scala library without needing language extensions, and control structures like break and even while (foo) { code } can likewise be implemented in libraries.

Unified type system [edit]

Java makes a sharp distinction between primitive types (e.g. int and boolean) and reference types (any class). Only reference types are part of the inheritance scheme. In Scala, however, all types inherit from a top-level class Any, whose immediate children are AnyVal (value types, such as Int and Boolean) and AnyRef (reference types, as in Java). This means that the Java distinction between primitive types and boxed types (e.g. int vs. Integer) is not present in Scala; boxing and unboxing is completely transparent to the user. Scala 2.10 allows for new value types to be defined by the user.

For-expressions [edit]

Instead of the Java "foreach" loops for looping through an iterator, Scala has a much more powerful concept of for-expressions. These are similar to list comprehensions in a languages such as Haskell, or a combination of list comprehensions and generator expressions in Python. For-expressions using the yield keyword allow a new collection to be generated by iterating over an existing one, returning a new collection of the same type. They are translated by the compiler into a series of map, flatMap and filter calls. Where yield is not used, the code approximates to an imperative-style loop, by translating to foreach.

A simple example is:

val s = for (x <- 1 to 25 if x*x > 50) yield 2*x

The result of running it is the following vector:

Vector(16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50)

(Note that the expression 1 to 25 is not special syntax. The method to is rather defined in the standard Scala library as an extension method on integers, using a technique known as implicit conversions^[20] that allows new methods to be added to existing types.)

A more complex example of iterating over a map is:

// Given a map specifying Twitter users mentioned in a set of tweets,
// and number of times each user was mentioned, look up the users
// in a map of known politicians, and return a new map giving only the
// Democratic politicians (as objects, rather than strings).
val dem_mentions = for {
    (mention, times) <- mentions
    account          <- accounts.get(mention)
    if account.party == "Democrat"
  } yield (account, times)

Note that the expression (mention, times) <- mentions is actually an example of pattern matching (see below). Iterating over a map returns a set of key-value tuples, and pattern-matching allows the tuples to easily be destructured into separate variables for the key and value. Similarly, the result of the comprehension also returns key-value tuples, which are automatically built back up into a map because the source object (from the variable mentions) is a map. Note that if mentions instead held a list, set, array or other collection of tuples, exactly the same code above would yield a new collection of the same type.

Functional tendencies [edit]

While supporting all of the object-oriented features available in Java (and in fact, augmenting them in various ways), Scala also provides a large number of capabilities that are normally found only in functional programming languages. Together, these features allow Scala programs to be written in an almost completely functional style, and also allow functional and object-oriented styles to be mixed.

Examples are:

• No distinction between statements and expressions
• Type inference
• Anonymous functions with capturing semantics (i.e. closures)
• Immutable variables and objects
• Lazy evaluation
• Delimited continuations (since 2.8)
• higher-order functions
• nested functions
• currying
• pattern matching
• algebraic data types (through "case classes")
• tuples

Everything is an expression [edit]

Unlike C or Java, but similar to languages such as Lisp, Scala makes no distinction between statements and expressions. All statements are in fact expressions that evaluate to some value. Functions that would be declared as returning void in C or Java, and statements like while that logically do not return a value, are in Scala considered to return the type Unit, which is a singleton type, with only one object of that type. Functions and operators that never return at all (e.g. the throw operator or a function that always exits non-locally using an exception) logically have return type Nothing, a special type containing no objects that is a bottom type, i.e. a subclass of every possible type. (This in turn makes type Nothing compatible with every type, allowing type inference to function correctly.)

Similarly, an if-then-else "statement" is actually an expression, which produces a value, i.e. the result of evaluating one of the two branches. This means that such a block of code can be inserted wherever an expression is desired, obviating the need for a ternary operator in Scala:

// Java:
int hexDigit = x >= 10 ? x + 'A' - 10 : x + '0';

// Scala:
val hexDigit = if (x >= 10) x + 'A' - 10 else x + '0'

For similar reasons, return statements are unnecessary in Scala, and in fact are discouraged. As in Lisp, the last expression in a block of code is the value of that block of code, and if the block of code is the body of a function, it will be returned by the function.

Note that a special syntax exists for functions returning Unit, which emphasizes the similarity between such functions and Java void-returning functions:

def printValue(x: String) {
  println("I ate a %s".format(x))
}

However, the function could equally well be written with explicit return value:

def printValue(x: String): Unit = {
  println("I ate a %s".format(x))
}

or equivalently (with type inference, and omitting the unnecessary braces):

def printValue(x: String) = println("I ate a %s".format(x))

Type inference [edit]

Due to type inference, the type of variables, function return values, and many other expressions can typically be omitted, as the compiler can deduce it. Examples are val x = "foo" (for an immutable, constant variable or immutable object) or var x = 1.5 (for a variable whose value can later be changed). Type inference in Scala is essentially local, in contrast to the more global Hindley-Milner algorithm used in Haskell, ML and other more purely functional languages. This is done to facilitate object-oriented programming. The result is that certain types still need to be declared (most notably, function parameters, and the return types of recursive functions), e.g.

def formatApples(x: Int) = "I ate %d apples".format(x)

or (with a return type declared for a recursive function)

def factorial(x: Int): Int = {
  if (x == 0)
    1
  else
    x*factorial(x - 1)
}

Anonymous functions [edit]

In Scala, functions are objects, and a convenient syntax exists for specifying anonymous functions. An example is the expression x => x < 2, which specifies a function with a single parameter, that compares its argument to see if it is less than 2. It is equivalent to the Lisp and Scheme form (lambda (x) (< x 2)). Note that neither the type of x nor the return type need be explicitly specified, and can generally be inferred by type inference; but they can be explicitly specified, e.g. as (x: Int) => x < 2 or even (x: Int) => (x < 2): Boolean.

Anonymous functions behave as true closures in that they automatically capture any variables that are lexically available in the environment of the enclosing function. Those variables will be available even after the enclosing function returns, and unlike in the case of Java's "anonymous inner classes" do not need to be declared as final. (It is even possible to modify such variables if they are mutable, and the modified value will be available the next time the anonymous function is called.)

An even shorter form of anonymous function uses placeholder variables: For example, the following:

list map { x => sqrt(x) }

can be written more concisely as

list map { sqrt(_) }

Immutability [edit]

Scala enforces a distinction between immutable (unmodifiable, read-only) variables, whose value cannot be changed once assigned, and mutable variables, which can be changed. A similar distinction is made between immutable and mutable objects. The distinction must be made when a variable is declared: Immutable variables are declared with val while mutable variables use var. Similarly, all of the collection objects (container types) in Scala, e.g. linked lists, arrays, sets and hash tables, are available in mutable and immutable variants, with the immutable variant considered the more basic and default implementation. The immutable variants are "persistent" data types in that they create a new object that encloses the old object and adds the new member(s); this is similar to how linked lists are built up in Lisp, where elements are prepended by creating a new "cons" cell with a pointer to the new element (the "head") and the old list (the "tail"). Persistent structures of this sort essentially remember the entire history of operations and allow for very easy concurrency — no locks are needed as no shared objects are ever modified.

Lazy (non-strict) evaluation [edit]

Evaluation is strict ("eager") by default, i.e. expressions are evaluated as soon as they are available, rather than as needed. However, a variable can be made non-strict ("lazy") with the lazy keyword, meaning that the code to produce the variable's value will not be evaluated until the first time the variable is referenced. Non-strict collections of various types also exist (e.g. the type Stream, a non-strict linked list), and any collection can be made non-strict with the view() method. Non-strict collections provide a good semantic fit to things like server-produced data, where the evaluation of the code to generate later elements of a list (that in turn triggers a request to a server, possibly located somewhere else on the web) only happens when the elements are actually needed.

Tail recursion [edit]

Functional programming languages commonly provide tail call optimization to allow for extensive use of recursion without stack overflow problems. Limitations in Java bytecode complicate tail call optimization on the JVM. In general, a function that calls itself with a tail call can be optimized, but mutually recursive functions cannot. Trampolines have been suggested as a workaround.^[21] Trampoline support has been provided by the Scala library with the object scala.util.control.TailCalls since Scala 2.8.0 (released July 14, 2010).^[22]

Case classes and pattern matching [edit]

Scala has built-in support for pattern matching, which can be thought as a more sophisticated, extensible version of a switch statement, where arbitrary data types can be matched (rather than just simple types like integers, booleans and strings), including arbitrary nesting. A special type of class known as a case class is provided, which includes automatic support for pattern matching and can be used to model the algebraic data types used in many functional programming languages. (From the perspective of Scala, a case class is simply a normal class for which the compiler automatically adds certain behaviors that could also be provided manually—e.g. definitions of methods providing for deep comparisons and hashing, and destructuring a case class on its constructor parameters during pattern matching.)

An example of a definition of the quicksort algorithm using pattern matching is as follows:

def qsort(list: List[Int]): List[Int] = list match {
  case Nil => Nil
  case pivot :: tail => {
    val (smaller, rest) = tail.partition(_ < pivot)
    qsort(smaller) ::: pivot :: qsort(rest)
  }
}

The idea here is that we partition a list into the elements less than a pivot and the elements not less, recursively sort each part, and paste the results together with the pivot in between. This uses the same divide-and-conquer strategy of mergesort and other fast sorting algorithms.

The match operator is used to do pattern matching on the object stored in list. Each case expression is tried in turn to see if it will match, and the first match determines the result. In this case, Nil only matches the literal object Nil, but pivot :: tail matches a non-empty list, and simultaneously destructures the list according to the pattern given. In this case, the associated code will have access to a local variable named pivot holding the head of the list, and another variable tail holding the tail of the list. Note that these variables are read-only, and are semantically very similar to variable bindings established using the let operator in Lisp and Scheme.

Pattern matching also happens in local variable declarations. In this case, the return value of the call to tail.partition is a tuple — in this case, two lists. (Tuples differ from other types of containers, e.g. lists, in that they are always of fixed size and the elements can be of differing types — although here they are both the same.) Pattern matching is the easiest way of fetching the two parts of the tuple.

The form _ < pivot is a declaration of an anonymous function with a placeholder variable; see the section above on anonymous functions.

The list operators :: (which adds an element onto the beginning of a list, similar to cons in Lisp and Scheme) and ::: (which appends two lists together, similar to append in Lisp and Scheme) both appear. Despite appearances, there is nothing "built-in" about either of these operators. As specified above, any string of symbols can serve as function name, and a method applied to an object can be written "infix"-style without the period or parentheses. The line above as written:

qsort(smaller) ::: pivot :: qsort(rest)

could also be written as follows:

qsort(rest).::(pivot).:::(qsort(smaller))

in more standard method-call notation. (Methods that end with a colon are right-associative and bind to the object to the right.)

Partial functions [edit]

In the pattern-matching example above, the body of the match operator is a partial function, which consists of a series of case expressions, with the first matching expression prevailing, similar to the body of a switch statement. Partial functions are also used in the exception-handling portion of a try statement:

try {
  ...
} catch {
  case nfe:NumberFormatException => { println(nfe); List(0) }
  case _ => Nil
}

Finally, a partial function can be used by itself, and the result of calling it is equivalent to doing a match over it. For example, the previous code for quicksort can be written as follows:

val qsort: List[Int] => List[Int] = {
  case Nil => Nil
  case pivot :: tail =>
    val (smaller, rest) = tail.partition(_ < pivot)
    qsort(smaller) ::: pivot :: qsort(rest)
}

Here we declare a read-only variable whose type is a function from lists of integers to lists of integers, and bind it to a partial function. (Note that the single parameter of the partial function is never explicitly declared or named.) However, we can still call this variable exactly as if it were a normal function:

scala> qsort(List(6,2,5,9))
res32: List[Int] = List(2, 5, 6, 9)

Object-oriented extensions [edit]

Scala is a pure object-oriented language in the sense that every value is an object. Data types and behaviors of objects are described by classes and traits. Class abstractions are extended by subclassing and by a flexible mixin-based composition mechanism to avoid the problems of multiple inheritance.

Traits are Scala's replacement for Java's interfaces. Interfaces in Java are highly restricted, able only to contain abstract function declarations. This has led to criticism that providing convenience methods in interfaces is awkward (the same methods must be reimplemented in every implementation), and extending a published interface in a backwards-compatible way is impossible. Traits are similar to mixin classes in that they have nearly all the power of a regular abstract class, lacking only class parameters (Scala's equivalent to Java's constructor parameters), since traits are always mixed in with a class. The super operator behaves specially in traits, allowing traits to be chained using composition in addition to inheritance. For example, consider a simple window system designed as follows:

abstract class Window {
  // abstract
  def draw()
}
 
class SimpleWindow extends Window {
  def draw() {
    println("in SimpleWindow")
    // draw a basic window
  }
}
 
trait WindowDecoration extends Window { }
 
trait HorizontalScrollbarDecoration extends WindowDecoration {
  // "abstract override" is needed here in order for "super()" to work because the parent
  // function is abstract. If it were concrete, regular "override" would be enough.
  abstract override def draw() {
    println("in HorizontalScrollbarDecoration")
    super.draw()
    // now draw a horizontal scrollbar
  }
}
 
trait VerticalScrollbarDecoration extends WindowDecoration {
  abstract override def draw() {
    println("in VerticalScrollbarDecoration")
    super.draw()
    // now draw a vertical scrollbar
  }
}
 
trait TitleDecoration extends WindowDecoration {
  abstract override def draw() {
    println("in TitleDecoration")
    super.draw()
    // now draw the title bar
  }
}

You can then declare a variable as follows:

val mywin = new SimpleWindow with VerticalScrollbarDecoration with HorizontalScrollbarDecoration with TitleDecoration

Then, the result of calling mywin.draw() will be

in TitleDecoration
in HorizontalScrollbarDecoration
in VerticalScrollbarDecoration
in SimpleWindow

In other words, the call to draw first executed the code in TitleDecoration (the last trait mixed in), then (through the super() calls) threaded back through the other mixed-in traits and eventually to the code in Window itself, even though none of the traits inherited from one another. This is similar to the Java decorator pattern (e.g. as used in Java's I/O classes), but is more concise and less error-prone, as it doesn't require explicitly encapsulating the parent window or explicitly forwarding functions whose implementation isn't changed. This design pattern in Scala has been given the name cake pattern.

Expressive type system [edit]

Scala is equipped with an expressive static type system that enforces the safe and coherent use of abstractions. In particular, the type system supports:

• Classes and abstract types as object members
• Structural types
• Path-dependent types
• Compound types
• Explicitly typed self references
• Generic classes
• Polymorphic methods
• Upper and lower type bounds
• Variance
• Annotation
• Views

Scala is able to infer types by usage. This makes most static type declarations optional. Static types need not be explicitly declared unless a compiler error indicates the need. In practice, some static type declarations are included for the sake of code clarity.

Type enrichment [edit]

A common technique in Scala, colorfully known as "pimp my library",^[20] allows new methods to be used as if they were added to existing types. This is conceptually similar to the C# concept of extension methods but more powerful, because the technique is not limited to adding methods and can for instance also be used to implement new interfaces. In Scala, this technique involves declaring an implicit conversion from the type "receiving" the method to a new type (typically, a class) that wraps the original type and provides the additional method. If a method cannot be found for a given type, the compiler automatically searches for any applicable implicit conversions to types that provide the method in question.

This technique allows new methods to be added to an existing class using an add-on library such that only code that imports the add-on library gets the new functionality, and all other code is unaffected.

Concurrency [edit]

Scala standard library includes support for the actor model, in addition to the standard Java concurrency APIs. The company called Typesafe provides a stack^[23] that includes Akka^[24], a separate open source framework that provides actor-based concurrency. Akka actors may be distributed or combined with software transactional memory ("transactors"). Alternative CSP implementations for channel-based message passing are Communicating Scala Objects,^[25] or simply via JCSP.

Scala also comes with built-in support for data-parallel programming in the form of Parallel Collections[1] integrated into its Standard Library since the version 2.9.0.

Testing [edit]

There are several ways to test code in Scala:

• ScalaTest supports multiple testing styles and can integrate with Java-based testing frameworks
• ScalaCheck, a library similar to Haskell's QuickCheck
• specs2, a library for writing executable software specifications
• ScalaMock provides support for testing high-order and curried functions
• JUnit or TestNG, two popular testing frameworks written in Java

Comparison with other JVM languages [edit]

Scala is often compared with Groovy and Clojure, two other programming languages also built on top of the JVM. Among the main differences are:

1. Scala is statically typed, while both Groovy and Clojure are dynamically typed. This adds complexity in the type system but allows many errors to be caught at compile time that would otherwise only manifest at runtime, and tends to result in significantly faster execution. (Note, however, that current versions of both Groovy and Clojure allow for optional type annotations, and Java 7 adds an "invoke dynamic" byte code that should aid in the execution of dynamic languages on the JVM. Both features should decrease the running time of Groovy and Clojure.)
2. Compared with Groovy, Scala has more changes in its fundamental design. The primary purpose of Groovy was to make Java programming easier and less verbose, while Scala (in addition to having the same goal) was designed from the ground up to allow for a functional programming style in addition to object-oriented programming, and introduces a number of more "cutting-edge" features from functional programming languages like Haskell that are not often seen in mainstream languages.
3. Compared with Clojure, Scala is less of an extreme transition for a Java programmer. Clojure inherits from Lisp and Scheme, with the result that it has a radically different syntax from Java and has a strong emphasis on functional programming while de-emphasizing object-oriented programming. Scala, on the other hand, maintains most of Java's syntax and attempts to be agnostic between object-oriented and functional programming styles, allowing either or both according to the programmer's taste.

Adoption [edit]

Language rankings [edit]

TIOBE Scala since 2006…2013‑04

As of March 2013, the TIOBE index^[26] of programming language popularity shows Scala at 31st place with 0.341% of the total programming market, while it was below the top 50 threshold the year before. Scala is now in the neighborhood of Scheme (29th), Prolog (34th), Erlang (33rd) and Haskell (32nd). Scala is well ahead of both Groovy and Clojure, the other two JVM-based languages that Scala is often compared with, both of which fall below 50th place. Similarly, the Transparent Language Popularity Index puts Scala at position 34, after Haskell and ahead of ML and Erlang.

The RedMonk Programming Language Rankings (which make use of popularity in Stack Overflow and GitHub) show Scala clearly behind a first-tier group of 11 languages (including Java, C, Python, PHP, Ruby, etc.), but leading a second-tier group, ahead of Haskell, Groovy, Clojure, Erlang, Prolog, Scheme and Smalltalk.

According to Indeed.com Job Trends, Scala demand has been rapidly increasing since 2010, trending ahead of Clojure but behind Groovy.

Companies [edit]

Many existing companies who depend on Java for business critical applications are turning to Scala to boost their development and improve productivity, application scalability and reliability.

Website online				Back office
AppJet	Atlassian[27]	Cisco Systems	Cloudify	Amazon.com	Autodesk Inc	Cake Solutions	Credit Suisse
Crossing-Tech SA	eBay Inc.[28]	…	Elmar Reizen bv	CSC[29]	EDF Trading	S&P Capital IQ[30]	…
Febo Beheer bv[31]	…	…	Foursquare[32]	Eligotech bv	…		HSBC
Gilt[33]	GridGain[34]	Heluna[35]	Klout[36]	IBM[37][38]	Intel[39]	Juniper Networks	Marktplaats.nl
LinkedIn[40][41][42][43][44]	LivingSocial.com	Lucid Software [45]	Mind Candy[46]	Micronautics Research
Meetup.com[47][48]	Novell[49]		OPower	Nasa[50]	Nature	New York Times	newBrandAnalytics
Plot[51][52]	precog.com	Reaktor	Remember The Milk[53]		Office Depot	Peerius.com	Quora.com[54]
SAP AG		Secondmarket.com	Siemens AG	Reverb Technologies, Inc.	Rhinofly[55]	Sears	Sony
Thatcham Motor	The Guardian[56][57]	TicketFly	Tumblr	StackMob[58]	Stanford PPL	TomTom	UBS[59]
Twitter[60][61]	Wattzon.com[62]	Wordnik.com	Workday.com	Walmart	Xebia	Xerox[63]	Zeebox[64]

In April 2009, Twitter announced that it had switched large portions of its backend from Ruby to Scala and intended to convert the rest.^[65]

Foursquare uses Scala and Lift.^[66]

GridGain provides Scala-based DSL for cloud computing.^[67]

In April 2011, The Guardian newspaper's website guardian.co.uk announced that it was switching from Java to Scala,^[68] starting with the Content API for selecting and collecting news content.^[69] The website is one of the highest-traffic English-language news websites and, according to its editor, has the second largest online readership of any English-language newspaper in the World, after the New York Times.^[70]

Swiss bank UBS approved Scala for general production usage.^[71]

LinkedIn uses the Scalatra microframework to power its Signal API.^[72]

Meetup uses Unfiltered toolkit for real-time APIs.^[73]

Remember the Milk uses Unfiltered toolkit, Scala and Akka for public API and real time updates.^[74]

See also [edit]

Free software portal

• Circumflex, Web application and other frameworks for Scala
• Lift, an open source Web application framework that aims to deliver benefits similar to Ruby on Rails. The use of Scala means that any existing Java library and Web container can be used in running Lift applications.
• Play!, an open source Web application framework that supports Scala
• Scalatra, a very minimal Web application framework built using Scala
• Simple Build Tool, a widely used build tool for Scala projects.

References [edit]

Further reading [edit]

External links [edit]

Wikibooks has a book on the topic of: Scala

• Official website
• Typesafe company website
• Scala community blogs
• Scala Forum
• Simply Scala - online version of the Scala REPL
• Scala communities around the globe
• Scala IDE, open source Scala IDE for Eclipse
• Compiling Scala to LLVM, Goeff Reedy.

v t e Java Java platforms Java language JVM Micro Edition Standard Edition Enterprise Edition Java Card Android SDK Sun technologies Squawk Java Development Kit OpenJDK Java virtual machine JavaFX Maxine VM Platform technologies Applets Servlets MIDlets jsp Web Start (JNLP) Major third-party technologies JRockit GNU Classpath Kaffe TopLink Apache Harmony Apache Struts Spring framework Hibernate JBoss application server Tapestry Jazelle History Java version history Java Community Process Sun Microsystems Free Java implementations Major programming languages BeanShell Clojure Groovy Oxygene Java Tcl JRuby Jython Processing Rhino Scala more… Java conferences JavaOne