Clojure & Scala Similarities - Twins separated at birth?

2010-04-21 10:17:46

Earlier today a blog post came up which was written by the Head of Development at a certain German company. He reviewed some meaningful similarities between Clojure and Scala, then finally concluded that the differences were actually only relating to syntax. This is exciting, so lets have a look!



Preface

It's always a delight when one of my fellow bloggers gets the ball rolling on a certain topic, because you get a new angle on things that you might previously have dismissed. In this case, I would have dismissed any similarities between Scala and Clojure immediately, but now that Stephan has presented his case, lets zoom in for a closer look - first at the similarities, then at the differences.


Similarities

Stephan lists no less than 7 bullets in his 'similarities' section, so it makes sense to walk then 1 by 1.

1. Scala and Clojure are more alike than different

Hmm. I think we will have to wait with that one, since its not really a similarity.

2. Both have strong focus on functional programming

I would have to disagree somewhat. Scala has been called a functional programming language by some of its users, but Scala-lang.org doesn't say so, instead it says that Scala integrates features of functional languages (like immutable data, folding left/right, etc) and this was indeed the impression I got while skimming Scala by Example (pdf). Then this is actually more a difference than a similarity, as Clojure forces you into functional thinking and architecture, enforcing special semantics when you stray from that path. That makes most Clojure programs functional, where Scala programs will be whatever the writer decides they should be, its an imperative language which functional features plugged in.

3. Both favor tight Java integration

I think this is true, as I have often seen Scala integrate nicely with Java and indeed Clojure does the same. Being on the JVM is definitely a meanful similarity, as both now plug in to the Java ecosystem, deploy everywhere, have automated GC etc etc.

4. Clojure is more Lisp style, but with Objects. (protocols)

Tecnically speaking, this is not actually similarity. Its true that Clojure is a Lisp-1, but that alone puts it miles and miles away from Scala. Being a Lisp means homoiconicity, meaning powerful macros and a host of other things, all of which Scala has no answer to. Also you should note, that protocols are in fact not objects, but I'll leave that for a separate post.

5. Scala is more C style, but with functions

Technically, this isn't a similarity either. But it is true, that Scala aligns well with the rest of the ALGOL family.

6. Both favor persistent immutable collections

I'm not sure what favor means in this case, but its true that both languages have such collections. Where Clojure forces you into them, Scala lets you choose. In fact one of the main arguments (I think) for Scala, is that "you can take a Java developer, put him into Scala and immediately he'll be effective". Now I don't actually think that 'effective' is the word, but the argument still tells me that the imperative style is as encouraged (favored?) as the functional.

7. Both favor new ways of concurrency, STM (Clojure), Actors (Scala)

This is true, but alone the fact that Clojure has an in-process shared memory concurrency semantic while Scala on the other hand relies on the less efficient and a little trickier actor model, would consitute a difference in my book as well. Don't get me wrong, actors are great - for message passing in distributed systems, not as an end-all-be-all concurrency solution. (though, smart people would disagree with me on this).


Differences

When we're counting differences we might as well start with Stephans 'similarities' above, as it turns out that when scrutinized only the JVM argument holds up. So why should one look at Clojure instead of Scala?

1. I think Clojure is much simpler

Clojure has a very simple syntax and some of the core idioms (first, second, last, map, reduce, filter, remove, etc) gives you more mileage than you could possible imagine if you haven't tried it.

2. Clojure is heavily oppinionated

Rich Hickey, the author of Clojure, has put a lot of thought into how he thinks the language can help you into writing better software. That means for instance, that the default is immutable datastructures and that no mutations can occur outside of specific semtantics (swap!, reset!, alter, dosync, etc).

3. Clojure is dynamically typed

That means, that if you can master it you can write truly reusable code which doesn't rely on specific types of arguments (ie, lists, vectors etc, all implement the same interface). In addition, dynamically typed languages make for rapid prototyping, where you dont have to settle on a type model up front.

4. Clojure is a Lisp

Being a Lisp is no small thing. There are more upsides than I care to list, and the only down-side is the learning curve which is tricky for some, but thats becoming fixed quickly.

5. Clojure is not OO

Clojure is not object oriented, which is a feature of Clojure. Once you wrap the architect part of your brain around this, you'll love it.


Conclusion

Clojure and Scala aren't twins separated at birth! And it makes little sense business-wise to think of it like that. There are valid reasons for choosing one language over the other and both requires careful study before you pick - Please don't narrow this down to a syntax issue as it is definitely not just that.

If you are new to Clojure I've tried to put some meaningful links in this post for you to check out, but you should also be able to find some good 'getting started' posts on this site as well. Also I'd like to invite Stephan and the rest of you to #clojure on irc.freenode.net, which is always a good place to get started.

Carl Smotricz
2010-04-21 14:14:58
Good post! When I first read Stephan's post, I found myself disagreeing with some of his assertions about similarities too.

One (obvious?) that he forgot to mention is that both run on the JVM and thus share the gigantic Java library ecosystem. Also, one could conceivably do polyglot programming with Clojure and Scala in the same app. Somewhere on the planet, there's a use case for that ;)

Another similarity is that both *compile* to bytecode. This means both languages let you write apps that perform comparably to Java and hence C/C++, etc. Apps in either language will tend to run circles around JRuby, Jython, Groovy (?) and others that tend toward interpreted mode.

Finally, Scala and Clojure are similar insofar as they're siblings; developed in very roughly the same timeframe, both by CS professors, with similar amounts of supporting resources like books and Web frameworks. So people became aware of them at roughly the same time.

That, though, is where it ends. 

Scala feels like a grandchild of Pascal, with a strong fixation on types. With its optional FP but OO compatibility, in some ways it's "a better Java than Java" and I see some potential to re-train some of the millions of Java "code monkeys" to code in Scala with somewhat less code and semicolons.

Clojure, on the other hand, is very different. It's so good it would make it worthwhile for many people to learn the Lispy idiom and FP. It's a whole different way of thinking, and would be a difficult retread for many "cubicle farm" coders. It takes some weeks to months to absorb the different paradigms, and most enterprises won't be willing to eat the costs. So while the move to Clojure can be very rewarding, as you've found, I think that only relatively few hardcore geeks will be making the move there. Sadly, my guess is that Clojure will likely remain a niche language.

Unless new concurrency requirements cry out for something like STM. Nearly effortless and foolproof concurrency are big advantages of Clojure.
Lau
2010-04-21 14:19:59
Hi Carl, thanks for checking in.

You're right so far that Clojure does compile to byte-code, which I thought was implicitly obviously when I wrote the post, until I remember all the interpreted languages! :) Thanks for bringing it up. I do feel its worth mentioning, that Scala precedes Clojure by almost 3 years I think and that Rich Hickey is not AFAIK a CS professor - They are inspired by different people and different books entirely.

Regarding your predictions about Clojures uptake, I personally think you're wrong because I'm seeing uptake which is rapid, extraordinary and above our expectations - Yet what the future holds, I don't know.
Craig Andera
2010-04-21 15:05:05
Rich taught for several years at one of the SUNYs. I don't know if he held the title of "professor" or not. It's certainly true that he has a very strong grounding in the literature - far more so than most.
whakojacko
2010-04-21 22:39:04
"    3. Clojure is dynamically typed

That means, that if you can master it you can write truly reusable code which doesn’t rely on specific types of arguments (ie, lists, vectors etc, all implement the same interface)."
Scala essentially lets you do the same do to the large amounts of collection commonalities (eg Seq)

"In addition, dynamically typed languages make for rapid prototyping, Fair point. Coming up with a good type system for a Scala library can be a lot of work.

@Carl Clojure may compile to java bytecode, but its still dynamically typed, which is going to give you some performance penalities
Rick
2010-04-21 22:53:33
It's a pretty good rebuttal to the comparison.   Unfortunately,  Clojure is just way too foreign for a serious uptake.  Seriously, its easy to say Clojure has a rapid uptake when its starting at 0 a couple years ago.  But s-expressions, and really a repudiation of Java-style OO just isn't going to sit well with your average corporate manager no matter what the benefits are.

The best thing to happen would be an algol syntax thrown on a Clojure modeled language ala Dylan, with some more optional type declarations and inference to give the IDEs a better understanding of the code.
pratik patel
2010-04-26 19:47:50
Rick,
Clojure is foreign, and that's a strength for those that know it. Serious uptake for Clojure depends not so much on the syntax & semantics, rather the advantages it provides over OO style langs. Once Company X starts using Clojure and gains a competitive advantage, Companies Y and Z will suddenly be very interested in finding some Clojure developers. Since Clojure interop with Java is good, managers won't have to "throw away" legacy code, but can continue to utilize their investment in their codebase while moving forward in a new (and improved) direction. Just my $0.02
Mark Swanson
2010-05-01 08:08:13
To no one in particular, just some comments about Algol derived languages and incidental complexity.

The problem I've had with Algol based OO languages is increasing incidental complexity over time. I used to just accept this as a cost of doing business but with Clojure I no longer have to.
People speak about the 4 legs of Clojure; I think they should speak more about how the sum of these parts results in wonderfully low levels of incidental complexity. The end result is a code base that's easier to maintain, extend, read, refactor compared to anything else I've ever used.