"Clojure for Lisp Programmers" Talk Summary

In his talk Rich Hickey made an overview of the major features of Clojure and the design rationale behind them. Except for being Lisp-1, as far as I understand, Clojure is mostly based in and inspired by Common Lisp. Moreover, it tries to push some of the CL technologies to even purer abstraction and generality.

I've tried to categorize the discussed features in their relation to Common Lisp:

1. Taken from CL and stretched/modified
   
   • destructuring
     
   • nil behavior in conditionals
     
   • defmacro
     
   • multimethods with dispatch by an arbitrary function of arguments
     

     Obviously is more general, than the CL variant, although Rich failed to mention, that CL's generic functions have also dispatch by EQL, which is enough for, I think, 95% of the situations.

     
     
   • first-class immutable & persistent data-types: list, vector, hash-map and set
     
   • seq(uence) protocol
     

     I consider the last 2 a very important idea and a good candidate for implementation as a CL library.

   
   
2. Intentionally different from CL
   
   • Side-effect free reader & separate symbol resolution for macros
     

     This is also a well thought-out choice, which gives a lot of food for thought.

     
     
   • Lisp-1. Symbols and vars separated (in Lisp-2 vars are symbol-value or symbol-function)
     

     In my opinion, not the best option. But it's, obviously, the simpler one to implement

     
     
   • egal equality
   
   
3. Additional technologies
   
   • STM (MVCC), agents & refs, commute
     

     A full-fledged innovative concurrent infrastructure.

     
     
   • Call-ability of data-structures as vars
     

     A controversial choice, which may lead to a lot of confusion.

     
     
   • Metadata
     

     In some sense, a substitute for lack of multiple-values. Besides, a partial introduction of support for the prototype pattern (although lacking inheritance).

   
   
4. Different from CL because of the need for JVM integration (CL solution being superior)
   
   • no multiple-values
     
   • namespaces instead of packages
     
   • boolean true/false
   
   
5. Arbitrary choices inferior to CL solutions (because too much work needed to implement & some infrastructure already available)
   
   • exception handling
     
   • debugging & profiling tools
     
   • boxed integers instead of numeric tower