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 tasks). 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 emotional way. Matt should just give it a few weeks' try, like Tim Bray did. Keith On Sun, Jan 17, 2010 at 12:00 PM, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> wrote: > 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 > -- > Mike Meyer <m...@mired.org> > http://www.mired.org/consulting.html > 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 clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com<clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en >
-- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
