Scala vs.Clojure, part 3 – the similarities

If you think the difference is only a syntax thing, you need to spend more time with Clojure (Lisp) macros. They change the game completely.

The fact that Clojure is a “functional first” language while Scala is an “object-oriented first” language completely dominates all other comparisons between the languages. Sure, they both have persistent collections, but the language is not about the code you write, it’s about *how* you write it.

Clojure and Scala are lightyears apart. Really, their only similarities are the fact that they both support functional idioms and they both run on the JVM.

On #4, I’d say rather that Clojure protocols are more like interfaces than like objects.

In terms of feel, I think the biggest difference is really the typing. Scala seems to be “more” than Java (although inferencing makes that ok in many cases) and Clojure is “less” than Java (dynamic but type hints pull you back towards Java). Depending on how you feel about types, you may be drawn towards one side or the other.

I think there is a case that macros are a difference but there is plenty of other stuff in Scala that I think allows you to solve those kinds of abstraction and language problems (at least those that occur in practice). (I don’t think compiler plugins are a fair answer.)

I actually proposed a Scala | Clojure talk with Jonas Boner for JavaOne this year called “Cool Hand Duke” about breaking out of Java. Of course, the chances that it will get accepted are about the same as Larry Ellison rewriting Oracle in Clojure.

Very interesting series of posts. Just read them all.

A while ago when I was thinking which one should I learn (mandatory because of all the parallelism and concurrency that we need to learn these days) I peek up Cloure because it’s pure functional and I don’t know nothing about FP.

So I decide to firstly learn FP with Clojure and after learn Scala and merge my OO and FP skills.

After all this I’ll be able to choose one of them for a real world project.

@stephan

Thanks for being gracious enough to entertain this discussion :)

In all fairness, I don’t have any experience w/ Scala. The following is based on experience w/ other languages like Ruby & Java…

I’ve thought about this for a bit, and I think the advantage of Lisp macros is centrally tied to the “code is data” philosophy. Everything is a data structure, so lisp macros manipulate data structures. The resulting data structure is then evaluated directly, with no intermediate steps.

The other big advantage is that Lisp macros are always available (and the system is always compiling). This means I can get information from a variety of sources.

This lets you do a lot of things. In the sysadmin world, *nix is so popular because it allows you to configure your systems with information stored in a file, retrieved over a network, or generated programmaticly. It allows for lots of tasks to be automated & centralized, and eliminates repetition.

This approach that works awesome in the sysadmin world seems to be promptly forgotten in the development world. As a result we repeat ourselves all the time, and create this unnecessary work. Lisp macros let me avoid this.

The only meaningful similarity is that they’re both on the JVM — which is an important connection. Other than that, just about everything is different enough to admit that they’re on completely different branches of the family tree.

I don’t think Scala and Clojure are similar except in a cursory look.
Yes, they both run in the JVM, both can interop with Java code (and each other) and both support functional programming and have some concurrency constructs.
But the “philosophical” basis of each language is totally different.
Clojure is a Lisp variant with concurrency constructs, with all the implications of lisp family: minimalist language, dynamic typing, metaprogramming / ultimate flexibility, lots of parenthesis :), “code is data”.
Scala is an OO-FP hybrid with inspirations in the ML family of functional languages, is static typed with an advanced type system aiming at providing “Scalable abstractions” where you can use the type system to ensure some properties on your code.

Is not just a syntax thing: is dynamic vs static typing :)

@Stephan

I’ve done a few videos on “code is data” if you’re interested…

http://vimeo.com/9114362

Macros make “code that writes code” a natural part of the development process.

Without macros, you can write code that writes code in other languages, but it generally runs as a separate pas, reading in what to it pure data, manipulating it as data, and then spitting out data that happens to be code when it’s done. I have done that before – using Cheetah to create Makefiles, or data structures to create XPath expressions. But this tends to mix two languages – the target language and the language that controls the generation of the final code. I also find that it’s a conceptual leap to go from writing code to writing code in a slightly different language that writes code.

With LISP macros, there’s only one language – it’s all LISP. It’s always there. Which means that going from writing code to realizing I need a macro to write that code is no longer conceptual leap – it’s just reaching for the next tool in the toolbox.

It’s an interesting discussion. I’ve just recently been asked to give an intro to Scala talk with comparisons to Clojure. So I’m also thinking about where they’re similar and where they’re different. There does seem to be a lot of interest in comparing the two languages, and as a replacement to Java with interoperability.

I’ve been programming Scala (and Java) for a couple of years in my current job, but previous to that I spent several years programming Lisp for AI research.

The static typing / dynamic typing seems to be a key difference, and one that might influence people one way or the other.

They do blur in a way, but fundamentally the static/dynamic difference is still there. My understanding of the type hinting in Clojure is that it’s to avoid reflection (by casting to the hinted type) but doesn’t provide any compile-time type checking. And thinking about type inference in Scala it seems to be more about conciseness. Statically typed languages are often perceived as verbose, while dynamic languages as concise. Haskell is the usual conter-example to this.

I find Daniel’s comment on “functional first” and “object-oriented first” interesting. Maybe larger project examples are needed to see how much of a difference this makes? I wonder if Scalaz shows that Scala can also be used in a way that puts functional over object-oriented?

Macros and Lisp’s code-as-data are very cool. Does anyone have some practical examples of using macros that would be too difficult to implement with Scala’s features?

Here’s a nice example in emacs lisp that really illustrates the concept of code as data and creating functions on the fly

http://translate.google.com/translate?hl=en&sl=pt&tl=en&u=http%3A%2F%2Fwww.diale.org%2Fdiff.html

Obviously the same thing can be written in Clojure.

James

Hi Stephan – Thanks for linking to gregosuri.com

It’s not “just” syntax: syntax is a very big thing.
The success of these new languages in becoming mainstream depends on how easy it’s going to be for mainstream programmers, most of whom code in some OO language with C-like syntax, to start using these languages.
My personal experience, having tried both recently, is that Scala is the winner here.
With a background in C, Java etc., Scala syntax is far easier to read (and write) – the Lisp-like syntax of Clojure, when you’re not used to it, takes too many brain-cycles to deal with, before you even get to figuring out what the program is supposed to be doing.
That means that more people (like me) are going to choose Scala, and that it’s going to be far easier to train Java/Python/Ruby people to use Scala (since initially it’s going to be very hard to hire anyone with prior experience in either).
Since they’re not that different in terms of the power they give developers (beyond what Java can), then in terms of future mainstream adoption syntax is going to have a big effect, and the winner here is Scala.

Would you be able to do a Erlang vs Clojure? I am considering moving towards Erlang as the main development platform and have been researching the topic lately! Thanks!

Hey Stephan,

Thanks for getting the ball rolling with this, I think its great to look at the similarities and differences, simply from a feature-aspect.

I’ve tried to walk through your bullets here:
http://www.bestinclass.dk/index.php/2010/04/clojure-scala-similarities-twins-separated-at-birth/

And unfortunately (as your commentators suggest), most of them don’t hold up under pressure. One key piece that I was missing in my post, was the scenarios where Scalas Type System would be the deciding factor in using Scala instead of Clojure for a given task, but I failed to think of any. Can you fill in the blank?

Best regards,
Lau B. Jensen

@Stephan,

I’m sorry to hear you feel that way. If you think apple/apple comparisons are more valuable than comparing solutions idomatic to both languages it would be great if you could write them up (the code) and I’d be happy to link them or depending on the amount, compile them all in a new blog post.

I can assure you that no member of the Clojure community have any interest whatsoever in producing comparisons which do not represent reality.

Thanks,
Lau

@Lau, for an example how you can benefit from Scala’s type system, check this presentation http://vimeo.com/10482466 about how you can ensure that a list won’t be empty at the time of writing the program.

Well if Lau discovers that scala has its functional strengths too (certainly hidden in the very cool scalaz library ) he might be surprised. The scala standard library offers all possibilities for the developer to choose while clojure with its pure functional approach forces the developer into a direction.

One thing which is important (IMO):
I think its quite important to emphasise that both scala and clojure encourage the functional programming theme on the jvm.
Which is IMO a very good thing.

To what extend that maybe topic of following ( endless) discussions.

But “just” that fact is important enough to me to take a closer look at both (say over Groovy)

regards andreas

The biggest difference might turn out to be the way Clojure models time versus Scala and others.

http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey

I agree with those who think the languages are pretty far apart.

Starting with the very dynamic nature of Clojure: Clojure does have type hints, yes, but they are meant to provide hints for optimization, and the whole ethos of Clojure is to wind up with a set of small, composable functions which do a single well-defined operation on a data structure. Note that this isn’t an object with methods, it’s a functional library. Clojure feels very procedural to someone coming at it from a more OO background. In contrast, Scala encourages OO design from the beginning, though it’s certainly not as pedantic about it as Java is.

Also, regarding macros: I imagine a small handful people who are interested in Scala and language design might read the one page of official documentation about how the plugin system works and then roll up their sleeves, dive into the source code, and write a plugin to implement some new bit of syntax or add in a feature to the language. In contrast, macros are a well-defined, often uysed language feature of many Lisps, and any Clojure tutorial is sure to mention defmacro. It’s part of the Clojure culture – a quick glance at the Clojure Google groups will confirm this.

Also, I surely can’t speak for Rich Hickey, but I do think it’s fair to say that he was interested in comping up with “another Lisp,” just one that was emphatically not Common Lisp.

Well, I’d say the only similiarities is the general JVM + functional setup of both languages. From this point on their design is completely different (even opposing each other), but as you rightly said, they both address some modern paradigms like STM. They are insomuch similar as they’re sharing the same “zeitgeist”…

On the other hand, maybe you’re into something: I know at least two long time lisp programmers that are totally sold on Scala…
Even if they come from opposite ends of the spectrum, they both allow to write very concise and expressive code and that’s what matters at the end of the day.
They’re kind of the ying and yang of the JVM :)