One Night With Clojure Makes a Scala Guy Humble
I do most of my work these days in Scala, but I have long been curious about Clojure, partly because of the mythology around Lisp and it’s potential superior productivity and possibility of self-generating code (Clojure is a Lisp dialect).
I’ve been reading about Clojure from time to time, tried little snippets from time to time, but never made any serious efforts to get deep into the language. On Sunday I took the plunge in rewriting a small, but important payments application I have had running in production for a few years in different guises. This was the third incarnation of the app, the first one was in Java from 2008, second in Scala from 2009, and now this, I still have the codebase of all three apps, so I could contrast and compare the results.
A simple metric generated with cloc, namely Lines of Code really blew me away about Clojure:
- Java version: 755 lines of code (LOC)
- Scala version: 419 LOC’s*
- Clojure version: 57 LOC’s
Yup, that’s right, the Clojure version is more than 10 times less code, and about 7-8 times less than it’s Scala equivalent. In fairness though, the Scala number is a bit misleading: it was written before I got really familiar with Scala, and could probably be condensed to about 150-200 LOC’s. But still, it seems Clojure has a 3-4x advantage on even Scala.
Clojure Impressions
At first, the LISP syntax of
Clojure looks bewildering to say the least for someone originating from
a non-Lisp background. However, once you get your head around the
basics and the basic forms, it is actually both very simple and compact
at the same time. My guesstimate is that it would be a lot quicker to
master Clojure than it would be to master Scala if you started today.
Using Clojure was a humbling experience, I’m certainly looking forward to doing more things in Clojure going forward. I strongly suspect my company will become a mixed Scala/Clojure “shop” as time goes on and I find the sweet spots for the different languages.
I’m not going to go and say that “Clojure is better than Scala” - I think they are both excellent languages, and I don’t really have a strong preference, other than looking forward to do more in Clojure as and when I find reasonable sized things to do to learn more (especially before making definite statements on pros and cons).
If you have yet to seriously check out Clojure, I strongly suggest that you do! The first few hours may be frustrating and bewildering (you have been warned), but once you get over it, it is worth the effort. If you’re looking for a good build system, Leiningen seems to be it, which certainly works better and simpler than something like Maven. There are a number of books available on Clojure, and this tutorial seems a good start for beginners as well.
Oh, and my new Clojure app went into production the same day I started writing it.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Michal Huniewicz replied on Wed, 2011/08/10 - 10:15am
I don't want to discourage anyone from learning Scala or Clojure. But how much is the LOC number worth as an indicator of anything, really? We read code a lot more often than we write it. Is less code necessarily easier to read and understand? Is
5 times better than
? I don't think so. I wouldn't judge a language by lines of code. That's just technical fetishism to me.
Tomasz Nurkiewicz replied on Wed, 2011/08/10 - 10:37am
in response to:
Michal Huniewicz
No, but I think that
IS 5x times better (and even shorter)... However I generally agree that less is not always better (Perl...) But it's always about readability: if the code is much smaller and still readable (employees filter {_.salary > 1000} - idiomatic Scala) you have much more space on your screen, i.e. you can see a bigger picture without loosing the details. I think it's worth it.
Artur Biesiadowski replied on Wed, 2011/08/10 - 11:33am
Do you think it would be possible to find out where the real LOC savings are in Clojure compared to Scala? Are algorithms more compact or is it just about all the declarations you need in scala to get types working right?
Let's not drag java into comparison, we know it cannot compete without closures.
Jonathan Fisher replied on Wed, 2011/08/10 - 2:09pm
Liam Knox replied on Wed, 2011/08/10 - 4:42pm
It means nothing. Why not write the code in Kanji for the Chinese developers and save some more characters? Or I could write a solution in one line of Perl
Look at the facts
1. Clojure is not going to solve any real Business problems any cleaner than Java or C for that matter.
2. Skillset: No one learns this and no one cares in Lisp 'academic' languages. This is a fact. We have spent 30 years on this and it is about time to give up.
3. Show me one Job rec for Clojure, or for that mattter Scheme or Lisp. Just because something is pretty doesn't mean it actually works
Aaron Bedra replied on Wed, 2011/08/10 - 6:27pm
Statement, not fact. Just to humor you though, here's a short list.
http://dev.clojure.org/display/community/Clojure+Success+Stories
Almost all of these companies have Clojure positions available. What really works is all relative. If someone can get something done quickly and elegantly and it performs it's intended functions without issue than it works. You can do that right or wrong in any language. If Clojure is the language that helps give people an edge in "real" business (and it certainly does, I know from actual experience) than I would consider it more than academic and very real.
LoC metrics are just a toy, I agree. I imagine there are plenty of scenarios where Scala could beat Clojure in a LoC contest. You should look a little further into what the Clojure community is doing though and see what it's really about before jumping to these conclusions. You might just like what you find.
Rajesh Pitty replied on Thu, 2011/08/11 - 12:09am
David Grant replied on Thu, 2011/08/11 - 2:14am
Frank Mora replied on Wed, 2012/07/25 - 9:50am
Michael Kimsal replied on Tue, 2012/08/21 - 6:32am
in response to:
Jonathan Fisher
"There's no doubt that less code makes maintenance easier"
Well, you're already hinting at this, but it doesn't necessarily make maintenance easier. It may make maintenance easier for the original author/team, but to someone new coming in to the project, it may make it harder to ramp up.
Channing Walton replied on Tue, 2012/08/21 - 2:25pm
Greg Tucker-kellogg replied on Tue, 2012/08/21 - 11:47pm
in response to:
Tomasz Nurkiewicz
Joseph Hirn replied on Thu, 2012/08/23 - 11:42am
in response to:
Michal Huniewicz
Yes.
I type less, consumer reads more. Multiply that by 10. You now have 50 vs 10 lines of code. SLOC is just another metric like any other that's been around for a while. It's been abused by both sides of the argument. What I i appreciaite about the more concise 1 liner is less noise. Don't make me think.