Category Archives: Scala

Scala vs.Clojure, part 3 – the similarities

There is some more discussion of Scala vs. Clojure. With the Oracle deal, and some discussions about the slow Java 7 release, it looks like Java is detoriating faster not slower. So discussions about Java succession increase. I’ve discussed Scala vs. Clojure here, here and here. Greg Osuri now adds his take in “Scala Vs Clojure”, What the market thinks and compares job numbers for Clojure and Scala.

What I found interesting was a comment to that post:

I’m not really sure why Scala and Clojure are always discussed side-by-side. Sure, they’re both relatively new languages and they are both on the JVM, but Scala and Clojure have vastly different philosophies.

Scala and Clojure are indeed very different, so why compare them? I’ve wondered the same in the past, because, hey, they just don’t look alike. And nothing less than “different philosophies”. As Jesper on Stack Overflow writes:

Note that Clojure and Scala are two totally different types of programming languages – Clojure is a functional Lisp-like language, it is not object oriented. Scala is an object oriented language which has functional programming features.

But then why are they compared and mentioned together? To some, Java looks to need a successor – see my Is Java dead? analysis – both languages have enough momentum to be discussed as one (contrary to Fan for example). Both are functional languages, both support objects, both favor concurrency. So they are remarkly alike. Only on the first look are they quite different, as Scala favors C style syntax for OO and FP while Clojure favors Lisp style syntax. But that’s only lipstick.

Similarities?

In detail, Scala and Clojure look quite similar:

  1. Scala and Clojure are more alike than different
  2. Both have a strong focus on functional programming
  3. Both favor tight Java integration and basing apps on Java libraries (with wrappers) – with Clojure having a little bit more autarky tendencies
  4. Clojure more Lisp style, but with objects (see protocols)
  5. Scala more C style, but with functions
  6. Both favor persistent collections (immutable)
  7. Both favor new ways of concurrency, STM (Clojure) vs. actors (Scala), but both support the other mechanism with agents in Clojure and STM in Scala or Scala CCSTM

Differences?

So you might wonder, with all those similarities, is it only a syntax thing? I might concur yes. You can think the same way in both languages, what you perhaps choose are differently thinking communities. The major difference is that Scala has very powerful type system – if you’re into that type of thing – Clojure is loosly typed, but can have type hints – also see here. There is a strong type focus in the Scala community, influenced by early adopters.

Hope this helped to clear some things up.

If you liked this post, might also be interested in some other post I wrote about the topic:

Scala Goodness: Structural Typing

Structural typing in Scala is the way to describe types by their structure, not by their name as with other typing. Structural typing reduces coupling and the need for inheritance. In Java you would mainly use interfaces instead of structural typing.

I go with the same examples as in “Scala Goodness: Compound types” so it’s easier to compare both solutions.

c:{ def call():Unit } describes a type which has a call method that returns nothing – like void in Java. The method does take all objects of types that satisfies this constraint. We can now use call on both classes:

You can also give your structural type a name with type aliasing:

With the same classes from above we get:

Both ways work with more than one method:

Calling with a new dog results in:

Structural typing is very useful if you are not able to modify classes to make them implement a trait or interface or if you want to reduce coupling and increase reuse. How does this relate to interfaces? The benefit of interfaces instead of structural typing is how they describe the roles of a class.

instead of

Scala glory!

See also:

Scala Goodness: Extractors

One Scala goodness is the unapply method to extract values.

Suppose we want to match a string if it does contain DogFood. In Scala we can use an object or class with an unapply method, which takes the input we try to extract values from and returns the extracted value. Because there needn’t be a match in every case, the value is wrapped in an Option. A simple extractor for DogFood might look like this:

The unapply method can be used in more contexts. Another usecase is to filter for comprehensions. The same DogFood object from above can be used to filter a list of Strings and only return Strings that contain dog food:

Unapply can extract more than one value. In such a case, the method needs to return a Tuple (Javaish):

We can now use the Dog object to extract more than one value:

This also works for assignment, just as with Tuple assignment:

Extractors in Scala even work with Squences. For an example see Daily Scala, a wonderful blog with Scala tips.

See also: