Questions. Please stop me and ask them.

However, some questions give rise to more questions! These must be deferred due to time constraints.

"What do you think about the paint job on Russell's Teapot?^[1]

However, please see me after this session, or email me with your question.

What will you take from this?

Depth versus excitement. Not even Gary Kasparov could teach you to play chess in such a short time-frame.

But he could certainly plant some seeds!

Beware of under-qualified internet commentators and snake oil vendors offering misleading advice.

I am more optimistic than Dijkstra.^[2]

It is not an objective to convince you of the importance of the concepts at hand or to present irrefutable and compelling cases — mostly due to time constraints.

Keep thinking. Keep asking questions.

Duplication! Let's refactor.

Then we passed in the two differing implementations of Stringer for the two use cases.

But...

Uh oh, more duplication — more refactoring!

So let's parameterise over the method types

Problem resolved? LinkedList?

What if we want to map something that is not only not Iterable, but it makes no sense for it to be Iterable? i.e. we couldn't even implement the interface if we wanted to.

Should we concede and use dynamic typing — any object that supports the map method? Or perhaps concede Java's static type system and use reflection?

Perhaps we want to do a bit more, such as remove elements of a certain criteria as we map?

Fundamentalist^[3] functional programming is founded on eschewing side-effects or impurities.

A side-effect is any function which acts on unstated free variables e.g. iterators, loops, uncontrolled I/O.

Consider java.lang.String, which we say is immutable. Really, we are saying all of its methods are referentially transparent.

Referential transparency (or purity) is the anti-thesis of side-effects (or impurity).

Not to be confused with idempotence.^[4].

The litmus test.

If:

g(f(args));
g(f(args));
            

is equivalent^[5] to:

final T t = f(args);
g(t);
g(t);
            

for any function g and any arguments to f (which we have called args) then we say that f is referentially transparent.

For example

g(s.charAt(i));
g(s.charAt(i));
            

is always equivalent (regardless of g) to:

final char c = s.charAt(i);
g(c);
g(c);
            

Therefore, charAt is referentially transparent.

Bad news; new is a side-effect. Ever wanted to hide that constructor for your immutable type?

More bad news; Java makes it extremely difficult to be rid of impurity.^[6]

Pure code produces composable units or "gluing smaller components to make larger components",^[7] while impure code produces endless repetition and poor abstraction.

Pure code permits higher (much higher) levels of abstraction and is the essence of eliminating repetition. Purity is DRY and more.

Pure code is significantly easier to reason about.

We want fewer bugs, higher abstractions, lesser hindrances to approaching purity, all within a flexible type system. Must we abandon the JVM or legacy Java code?

var declares a mutable cell. Analogous to a non-final in Java. Avoid the use of var unless in exceptional circumstances.

val declares an immutable cell that is evaluated at its declaration point. Analogous to a final in Java.

def declares an immutable cell that is evaluated upon each use. An argument list may follow. Analogous to a method in Java.

lazy val declares an immutable cell that is unevaluated until first use.

Example (welcome to the Scala interpreter)

scala> val a = 7
a: Int = 7

scala> def b = 8
b: Int

scala> def c(n: Int) = n + 42
c: (Int)Int

scala> var d = 9
d: Int = 9

scala> lazy val e = 10
e: Int = 10
              

Scala's if/else combines Java's if/else and only ternary operator ?:.

Example

scala> val t = if(true) 7 else 8
t: Int = 7

scala> if(false) println("foo") else println("bar") // side-effect
bar

scala> println(if(true) "foo" else "bar")
foo
              

Scala has first-class functions. Very similar to the Java 7 BGGA proposal.

Java doesn't but we emulate it with interfaces — often with extravagant identifier names:

interface Function<A, B> {
  B call(A a);
}

interface DatabaseWalloper {
  Walloped wallop(Connection a);
}
              

In Scala, instead of passing a Function<String, Integer>, we pass String => Integer and instead of function.call(a) we write function(a).

scala> def reverseParse(s: String, f: String => Int) = f(s.reverse)
reverseParse: (String,(String) => Int)Int

scala> val c = reverseParse("5632", Integer.parseInt(_))
c: Int = 2365
            

Since functions are first-class we can do other clever things with them, like compose them.

scala> def compose[A, B, C](f: B => C, g: A => B): A => C = (a: A) => f(g(a))
compose: [A,B,C]((B) => C,(A) => B)(A) => C
            

trait is like a Java interface but allows mixin composition.

scala> trait Foo { def bar(n: Int): String }
defined trait Foo

scala> trait Bar
defined trait Bar

scala> trait Baz extends Foo with Bar { val baz: java.util.LinkedList[Int] }
defined trait Baz
              

class is similar to a Java class, however case class has no Java equivalent.

scala> case class Person(name: String, age: Int)
defined class Person

scala> val p = Person("Bob", 42)
p: Person = Person(Bob,42)

scala> val z = p.name
z: String = Bob
              

A sealed class or trait restricts possible subtypes to the declaring source file. Java has an obtuse equivalent by exploiting the fact that only nested classes may subclass a class with an inaccessible constructor.

sealed types and case class are used to denote Algebraic Data Types.

In Java, a List<String> is not a List<CharSequence> even though a String is a CharSequence.

void m1(java.util.List<CharSequence> s) {}
void m2(java.util.List<String> s) { m1(s); } // bzzt!
              

Java's type parameters are always invariant, but would be nice if they were covariant^[9].

Covariance doesn't mix well with side-effects^[10]

But we aren't married to them anymore! We can have covariance, at a small cost — since we are still dating them. We use + to denote covariance^[11]

scala> trait List[+A] { val head: A; val tail: List[A] }

scala> val x = new List[String] { val head = "abc"; val tail = null }

scala> val y: List[CharSequence] = x
              

The import keyword is used for importing packages.

Packages are hierarchical; foo.bar has access to everything in foo. This also applies if adding to existing Java code. e.g. your Scala source file in java.util.concurrent has access to Java collections (java.util) without importing.

Imports may contain multiple entries import java.util.{LinkedList, HashSet}.

Imports may wildcard import java.util._ or import java.util.Collectons._.

Imports may appear anywhere in a source file and are scoped accordingly.

We don't have to explicitly specify type annotations.

But we can still have static verification!

scala> val t = 7
t: Int = 7

scala> t.length
<console>:6: error: value length is not a member of Int
     t.length
            

However, sometimes we must explicitly type annotate to help out the inferencer. e.g. method arguments, recursive calls.

Since functions are first-class, we can pass them just as we do for any argument.

A function that accepts a function as an argument is a higher-order function.

The Scala library includes some higher-order functions

  people.filter(_.age > 20)

  people.sort((p1, p2) => p1.name < p2.name)
                
  (1 to 15).filter(even)
              

We use the visitor pattern in traditional OO to get around the problem of wanting to add a method to an interface and all its implementations.

Suppose we wish to use a collection that always has only zero or one element and we wish to dispatch based on this.

interface OneOrNone<T> {
  <A> A visit(OneOrNoneVisitor<A> v);
}

abstract class One<T> implements OneOrNone<T> {
  public <A> A visit(OneOrNoneVisitor<A> v) { return v.visit(this); }
  abstract T one();
}

class None<T> implements OneOrNone<T> {
  public <A> A visit(OneOrNoneVisitor<A> v) { return v.visit(this); }
}

interface OneOrNoneVisitor<A> {
  <T> A visit(One<T> o);
  <T> A visit(None<T> n);
}
            

So you write a function that uses the visitor.

class You {
  static <X> String stringOne(OneOrNone<X> o) {
    return o.visit(new OneOrNoneVisitor<String>() {
      public <T> String visit(One<T> o) { return "got it! " + o.one(); }
      public <T> String visit(None<T> n) { return "don't got one"; }
    });
  }
}
            

We are effectively destructuring into one of two parts, where one of those parts contains a value, while the other doesn't.

Instead, we do away with the visitor code and create an Algebraic Data Type.

sealed trait OneOrNone[+A]
final case object None extends OneOrNone[Nothing]
final case class One[+A](a: A) extends OneOrNone[A]
            

Then we pattern match when destructuring:

def stringOne[X](o: OneOrNone[X]) = o match {
  case One(o) => "get it! " + o
  case None => "don't got one"                
}
            

Much tidier!

Consider the set of natural numbers^[12].

sealed trait Natural
final case object Zero extends Natural
final case class Succ(s: Natural) extends Natural
            

We can now write a function to add two natural numbers.

def add(x: Natural, y: Natural): Natural = x match {
  case Zero => y
  case Succ(t) => add(t, Succ(y))
}

scala> val k = add(Succ(Succ(Zero)), Succ(Zero)) // add 2 1
k: Natural = Succ(Succ(Succ(Zero)))
            

We destructure algebraic data types using pattern matching — the case and match keywords.

We could write many functions over this algebraic data type.

Lists are extremely common in high-level programming.

sealed trait List[+A]
final case object Nil extends List[Nothing]
final case class Cons[A](h: A, t: List[A]) extends List[A]
            

Singly-linked list, however, unlike what you may be used to, lists are immutable! We prepend to lists, not append^[13] and we do not do it destructively.

Immutability leads to sharing. You can pass your list all around the place and nobody is going to update it — not just by promise, but not even the most malicious method could.

The Option structure is a list that contains 0 or 1 element ( sound familiar?) — and is not recursive like List.

sealed trait Option[+A]
final case object None extends Option[Nothing]
final case class Some[+A](a: A) extends Option[A]
            

Option is a better null than null.

Consider a Map.get(K) that returns an Option[V] — not just a V.

The flatMap method is one example of a method written over the Option algebraic type.

X x = method1(args1);
if(x == null) return null;
else {
  Y y = method2(x, args2);
  if(y == null) return null;
  else return method3(y, args3);
            

Ick!

method1(args1) flatMap (method2(_, args2)) flatMap (method3(_, args3))
            

The Either algebraic type is exceptional in that it was authored by an incredibly handsome person.

The Either data type represents logical disjunction — this or that.^[14]

Have you ever wanted to return one type or another, depending on the input?

Typically, you'd write a class to represent the disjunctive nature of this requirement — perhaps using the visitor pattern again and dispatching polymorphically.

Either is a better recoverable exception model than Java exceptions.

There are many others; pairs (logical conjunction), functions (logical implication), lazy lists, trees.

And of course, you can write your own.

In Java, all methods are in uncurried form.

They take zero or more arguments and return a value e.g. (A x B x C) -> D.

In curried form, A -> B -> C -> D where the -> associates to the right A -> (B -> (C -> D)).

We can partially apply each argument, getting back a function (that we can apply another argument to) or we get back a value.

Since Java is always uncurried, we often use constructor arguments to work around it or a factory.

Then, every use of the object has the constructor arguments applied.

Foo foo = new Foo("foo");
foo.method("bar"); // method uses the value "foo" by accessing a field            
          

Consider a trivial example Encoder -> String -> byte[].

Encoder e = new Encoder("UTF-8");
byte[] encoded = e.encode(contents); // has UTF-8 applied.
          

In Scala, we can partially apply arguments to return new functions.

scala> def add(x: Int)(y: Int) = x + y
add: (Int)(Int)Int

scala> def foo = add(7) _
foo: (Int) => Int

scala> val h = foo(8)
h: Int = 15            
          

We can get very funky indeed.

scala> val i = List(1, 2, 3) map foo
i: List[Int] = List(8, 9, 10)
          

Our encoder.

scala> def encoder: String => String => Array[Byte] = null // todo
encoder: (String) => (String) => Array[Byte]
            
scala> def utf8 = encoder("UTF-8")
utf8: (String) => Array[Byte]

scala> def encoded = utf8("contents")
encoded: Array[Byte]
          

The remaining concepts are quite deep and advanced and each of them can initiate lengthy discussion.

What have we seen so far?

What you have seen today may appear intimidating or overwhelming in theoretical foundation.

Some of the more advanced concepts are those that are the most exciting and incredibly powerful, however, they typically require some pre-requisite understanding.

Let's not burn our brains just yet anyway.

Take the following with light steps and don't feel intimidated if you do not follow.

In Java, we can abstract over type variables. After all, we don't write a length function for List<String>, List<Integer>, List<Person> and so on.

With Scala, we can abstract over type constructors.

trait Mappable[F[_]] {
  def map[A, B](fa: F[A], f: A => B): F[B]
}
          

Some type constructors that are Mappable:

Scala arguments may be annotated to defer their evaluation.

This can be very dangerous in an environment with uncontrolled side-effects, but also gives excellent compositional properties. Be careful!

scala> def and(x: Boolean, y: => Boolean) = x && y
and: (Boolean,=> Boolean)Boolean

scala> val r = and(false, throw new Error("blow up!"))
r: Boolean = false
            

Since we have higher-kinds we can model some high-level abstractions, including those from the king of abstraction — Category Theory.

Adding methods (!> and unless) to Boolean to perform a side-effect depending on the value.

(7 > 6) !> println("seven is greater than six")
(6 > 7) unless println("six is not less than seven")
            

Addings methods to any reducible container.

List(1, 3, 5) any even // false
Array(1, 2, 3) all even // false
List(2, 6, 8, 9, 6, 7, 3, 5, 8, 6, 9) selectSplit even // List(List(2, 6, 8), List(6), List(8, 6))
"age=54&name=Bob&address=At Home".toList selectSplit (_ != '&') > (_.mkString) // List(age=54, name=Bob, address=At Home)
            

The Functor.

List(1, 2, 3) > (_ + 1) // List(2, 3, 4)
Some(1) > (_ + 1) // Some(2)
None > (_ + 1) // None              
            

The Monad.

Some(7) >>= (x => if(x % 2 == 0) None else Some(x + 1)) // Some(8)
Some(8) >>= (x => if(x % 2 == 0) None else Some(x + 1)) // None
Some("a").replicate[List](3) // Some(List(a, a, a))
            

The MonadPlus.

List(1, 2, 3) <+> List(4, 5, 6) // List(1, 2, 3, 4, 5, 6)
Some(7) <+> Some(8) // Some(7)
Some(7) <+> None // Some(7)              
            

The Applicative functor.

Some(7) <*> (None > add2) // None
Some(7) <*> (Some(8) > add2) // Some(15)
List(1, 2, 3) <*> (List("a", "b") > (s => n => n + s + n)) // List(1a1, 2a2, 3a3, 1b1, 2b2, 3b3)
            

The Traversable.

Some("789") traverse ((_: String).map(_ - 48).toList) // List(Some(7), Some(8), Some(9))
List("abc", "def", "ghi") ->> // abcdefghi
Array(true, false, false, true, false) ->> // true (using the disjunction monoid)