The Case for Clojure
Background
At NFJS shows, a common question is "I only have time to learn one new language on the JVM: which should I pick?".
The easy answer is true: it doesn't matter. Just pick one already!
However, I think people can reasonably ask for more information.
Even though my personal favourite is Groovy, I fancy that, like a good law professor, I could argue a decent case for any of them.
In this post, I'll write a bit on Clojure. To be honest, the title is deceiving: I don't know Clojure, and this isn't a full-blown legal case. I'm really inviting you to some resources (see below).
However, I know enough to see the benefit. This is an earnest post.
Mark Volkmann is giving a Clojure talk on Thursday at the St Louis JUG. Quoting from his intro, Clojure is a dynamically-typed, functional programming language that runs on the JVM.
From past talks, and from Mark's intro, here are some reasons I think Clojure is worthy of your consideration:
Let's Lisp Again, Like We Did Last Semester
If you liked Lisp back in university, welcome back: Clojure has a Lisp-like syntax and style. Both the syntax and functional programming seems new again, in part thanks to Stuart Halloway's book.
Here, 'new' means a shot-in-the-arm to the FP community and a welcoming online scene. Let's face it: it can be lonely when studying older languages.
Got Lisp?
If you don't know Lisp or functional programming, adding Clojure to your repetoire is almost like right-brain thinking. It is profoundly different from Java, C#, and other imperative languages. This is important in order to truly grow. To borrow from natural languages: it's cool if you know French and Spanish, but it's cooler if you know French and Chinese (or Spanish and Chinese).
Bonus: though not unique to FP, Clojure can execute data as code. This is powerful, and quite underrated, IMHO. This goes all the way back to grand-daddy Lisp, so you'll be learning from one of the undisputed giants. What's more both Lisp and Clojure have a minimal, consistent syntax. Though it is, er, mind-expanding at first, many people become true fans of the philosophy.
Software Transactional Memory
Concurrency is the new memory management. Memory management was a beast until garbage collection evolved, over decades, to be a shining sword.
Now, on the JVM, we've tamed the memory beast and wrestle with concurrency. Consider books like this: JCiP is an outstanding book, but it is a tough go, in part because the developer must coordinate lock-level tools. Or, worse, a team of people must coordinate lock-level tools.
What if we had something really different -- a pseudo-intelligent agent like a garbage collector, except aimed at concurrency? That's what Clojure offers: a unique alternative that might (and that's all we can say: might) slay the beast of our time.
The Upshot
Come on out to the JUG on Thursday, or if you aren't in St Louis, check out Mark's excellent article on Clojure. It is quite thorough, and has received kudos from the Clojure community.
7 comments:
Cliff Click (from Azul) is doing a talk on how dynamic languages scale on the massive Azul boxes (100s/1000s of cores) at JavaOne. Somewhere I saw him mention that a Clojure app with STM scaled linearly up to 600 cores with no changes. That's one data point, but how can you not be interested in that!
I will also mention that if you are a data structures / collections freak then you will find no finer topic than the persistent (as in immutable) data structures that are the secret sauce of Clojure. The work Rich has done there, especially with the map, is truly innovative and awesome.
Even if you're not into the concurrency yet, (as Alex pointed out), the unification of sequences is really a thing of beauty in Clojure.
Now for the bad. Clojure definitely isn't a flash in the pan, and I'm sure it'll be used in production at many places, but s-expressions are just too weird for too many developers.
If someone would write an alternative reader (I know clojure doesn't allow user reader macros) that say had some nice python-like syntax, Clojure would probably be the number one alternative JVM language
Lisp is a family of languages, and Clojure *is* a Lisp, so it sounds funny to hear you speak of "Lisp and Clojure". :-)
It would be interesting to hear more about the "on the JVM" clause in the first paragraph. I haven't heard anybody speak about languages specific to one platform in decades -- why is this a useful consideration again today?
"s-expressions are just too weird for too many developers."
10 years ago, CSS was just too weird for designers. 20 years ago, OO was just too weird for many programmers. 30 years ago, compilers were just too weird.
Powerful new abstractions always seem weird to the average person. Otherwise they wouldn't be powerful new abstractions! Programmers are going to have to get over it, if they want the benefits.
"If someone would write an alternative reader (I know clojure doesn't allow user reader macros) that say had some nice python-like syntax"
Gee, Lisp programmers have only been trying to figure that one out for the past 50 years. :-)
Steele and Gabriel, 1993: "[W]e expect future generations of Lisp programmers to continue to reinvent Algol-style syntax for Lisp, over and over and over again, and we are equally confident that they will continue, after an initial period of infatuation, to reject it. (Perhaps this process should be regarded as a rite of passage for Lisp hackers.)"
10 years ago, CSS was just too weird for designers. 20 years ago, OO was just too weird for many programmers. 30 years ago, compilers were just too weird.And for 50 years, Lisp has been trying to gain traction...enough said.
Steele and Gabriel, 1993: "[W]e expect future generations of Lisp programmers to continue to reinvent Algol-style syntax for Lisp, over and over and over again, and we are equally confident that they will continue, after an initial period of infatuation, to reject it. (Perhaps this process should be regarded as a rite of passage for Lisp hackers.)"Bad logic there. Lisp programmers are already programming Lisp...duh.
It's the Java, C#, Python, Ruby, PHP that need to be brought into Clojure.
But they'll just reject it because of the syntax.
I guess "the lisp community" will never learn.
@Alex. Very cool! That is going to be huge exposure for Clojure
re: data types/sequences. Yes. I had to write my post quickly and wanted to highlight Mark's talk and article. However, this is a major omission from the post.
re: JVM. From Mark's intro, it looks like Clojure will be ported to the CLR. Either way, an immediate benefit is the familiar libraries (though some say that they don't always fit into a pure FP style). Another huge benefit is that many tough problems are solved: packages, distribution, i18n, etc, and the solutions are, again, familiar.
re: Lisp fighting for 50 years. I think we all share a certain disdain for trendy excitement about something we've seen years ago; yet, why criticize enthusiasm? Sometimes it just takes an idea to hit at the right time.
re: CSS. IMO, if XSLT can make it as an accepted technology, then surely Lisp can make it.
Mark my words: if there is a killer app that exploits a given technology, then we will all be learning that technology, and the books and tutorials will come pouring in. S-expressions are no exception to this. I don't know if STM will _be_ that kind of technology, but that's what makes this interesting to watch.
Post a Comment