I dropped in to hear Rich Hickey talk about Clojure at the New York Semantic Web meetup group.  Some highlights:

• Some programs, like compilers or theorem provers, are themselves functions.  They take input and produce output.  Purely functional languages like Haskell are good for these kinds of programs.  But other programs, like GUIs or automation systems, are not functions.  For example, a program that runs continously for months or years is not a function in the mathematical sense.  Clojure is mostly functional, but not purely functional.

• Most Clojure programmers go through an arc.  First they think “eww, Java” and try to hide all the Java.  Then they think “ooh, Java” and realize that Clojure is a powerful way to write Java code.  Rich frowns upon “wrapper” functions in Clojure that do nothing but wrap a Java method.  Calling the Java method directly is faster and easier to look up in JavaDoc.

• Rich recommended a paper, Out of the Tar Pit, for a discussion of functional and relational techniques to manage state.

• Clojure’s data structures are persistent.  This isn’t persistent in the stored-in-a-database sense.  It refers to immutability.  For example, adding an element to a vector creates a new vector that shares structure with the old one.  Because all data structures are immutable, this is both safe and efficient.  Clojure’s hash maps, for example, have time complexity of log-base-32, which is so small it’s practically constant.

• The first thing Rich did when experimenting with the semantic web was to pull data out of the Jena API and get it into Clojure data structures.  That allows him to leverage the full power of Clojure’s data manipulation functions.  This opens up a world of possibilities that he wouldn’t have if he stuck with Jena objects.  Basically, having your data trapped inside objects is bad, because you’re limited to whatever methods those objects provide.  With generic data structures, you can re-use and compose all the functions that Clojure already provides.

Screencasts and code from the talk should appear soon — watch clojure.org or the Clojure Google group for an announcement.

I dropped by the Java Users’ Group meeting last week since Rich Hickey was there to talk about Clojure.

I expected a bit of carping from the Java guys, and at first they were all “efficiency this” and “security that.”  But by mid-way through the talk I think they were getting it.  A few even got excited about macros.

If I didn’t make it clear in my first post about Clojure, I like this language.  Here’s some more reasons why:

1. All binding constructs — let, defn, and the like — perform destructuring.
2. Universal data structures — vector, list, map, set.
3. Built-in java.util.regex support.
4. Sixty squintillion Java libraries.
5. A small but growing number of Clojure libraries, some written by yours truly.
6. You can generate Java .class files that run Clojure code.
7. Lightning-fast bug fixes from the author.

The most famous piece of Lisp-related vaporware is vapor no longer: Arc has been released. After paging through the tutorial, I’m a bit underwhelmed. It looks like just a bunch of syntactic sugar implemented on top of Scheme. Clojure is more interesting and more innovative. Clojure and Arc have some things in common: data structures are functions on their keys, strings are sequences, and lambda is “fn”. But Arc seems to be more in the traditional, semi-imperative model whereas Clojure borrows heavily from functional programming. Arc even has for-loops, for goodness sakes. Obviously, I have no idea what else Paul Graham may have up his sleeve, so maybe there’s much more exciting stuff to come. But for now Arc looks to me like a modest improvement on Common Lisp / Scheme rather than a major new language.