I don't think you can really answer the question because it being asked in
the way it that precludes a good enough answer. The tone of Matt Raible's
request suggests that he'd really rather not learn it, and that there's no
possible reason to overcome that reluctance.
Why travel? There's plenty of good food right here, and interesting cultural
sites to see, and stuff to buy. But you don't ask that question: you just
go, and FIND OUT why it was worth doing after the fact. (Or maybe not.)
Still. My take:
1. Clojure is dynamic like Groovy, and functional like Scala, so if Matt
learned it, he'd be able to see what that's like.
2. It's a Lisp, and that's worth trying at least once, but it's on the JVM
and a new dialect, so it lets you write Java in Lisp at first, and the lets
you enjoy beginning to see new ways of thinking about problems.
3. Clojure has a flavor of STM that's database-like, and easy to use for the
non-theorist programmer (i.e., folks like me who just write dorky business
apps that aren't much more than shoving data to/from the web/database). This
really cuts down on "threading" bugs, which are super hard to diagnose when
the errors occur in production, which is always locked down and inaccessible
to devs, debuggers, etc. STM doesn't help distributed concurrency (for which
actors are better, imho), but it does help for a wide range of
non-distributed use cases.
4. Clojure's macros make domain specific languages a natural part of
programming. While Groovy's various Builders are pretty nice, it's not so
easy to write your own builder, esp. if you're under pressure to get
something done. For instance, I write a lot of Groovy apps, and I want
something like Compojure. But the idea of figuring out how to use the
Builder Support to do something like that just makes me tired.
Really, though, it's so hard to convince someone that one language is better
than another significantly enough to be "worth learning" using "reason" or
any other method. One just has to try it.
For me, Clojure/Lisp just works the way I do. Incremental, small functions,
interactive, etc, etc generally as a result of super-vague requirements.
Every time I write an app in it, I feel like the app gets smaller and
simpler over time. I let myself write a lot of boilerplate (to avoid
premature abstraction), then condense it all in a way that fits my app (not,
say, a general lib), and the whole experience of it is positive. Better,
smaller code, faster, and more fun to do (even if it's the same old business
So, Clojure "wins" or is "worth trying" because of the experience of using
it, not because of some particular bullet point, which all languages feel
like they all have.
(Personally, I'd really love Haskell/Erlang like pattern matching, not just
destructuring or multi-methods (but those, too!), but even so....)
Didn't Paul Graham say something to the affect that a user of a "blub"
language just can't see the point in other languages? I don't think Groovy
and Scala are blub languages, but I think the idea applies, at least in an
Matt should just give it a few weeks' try, like Tim Bray did.
On Sun, Jan 17, 2010 at 12:00 PM, Mike Meyer <
> On Fri, Jan 15, 2010 at 8:22 PM, Julian <juliangam...@gmail.com> wrote:
> > Matt Raible - Spring Expert and Java consultant posted the following
> > entry to Twitter:
> > "Why is Clojure better than Scala or Groovy?"
> How about two reasons to learn Clojure instead?
> 1) Clojure is (a) LISP. According to Eric Raymond, "LISP is worth
> learning for a different reason — the profound enlightenment
> experience you will have when you finally get it. That experience will
> make you a better programmer for the rest of your days, even if you
> never actually use LISP itself a lot."
> 2) Clojure is designed from the ground up for concurrent
> programming. It has a number of mechanisms that improve on locks for
> managing state. Those come from other languages, and are liable to
> appear in yet more languages in the future. If you're doing concurrent
> programming, learning them will make you a better concurrent
> programmer. If you're not doing concurrent programming, consider that
> CPU improvement has changed from an exponential growth in raw speed to
> an exponential growth in number of cores.
> Mike Meyer <m...@mired.org>
> Independent Network/Unix/Perforce consultant, email for more information.
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to email@example.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> For more options, visit this group at
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to firstname.lastname@example.org
Note that posts from new members are moderated - please be patient with your
To unsubscribe from this group, send email to
For more options, visit this group at