Honestly, I'm far more of a Schemer than a... Clojurite?Clojurist? Clojourneyman? I did try to make the switch to Common Lisp back in 2006, but I wasn't happy and went back to Scheme. Still, I'm far more interested in learning Clojure than giving Common Lisp another try. Here's what makes the difference for me:

1)Library support. With Clojure, it's a five minute import to get Bessel functions. When I asked about how to do Bessel functions in 2006, I was told to write it myself. I've heard things have become better since then, but I haven't been able to find any evidence that

2)Immutable data structures. Yes, this can be implemented as a library in CL. However, having it as the default means that I know every non-Java function I call isn't going to break that assumption. If I did find a Bessel function library, I can't assume that it's safe.

3)GUI support. In 2006, I needed to write a GUI application that ran on Windows, Mac, and Linux. PLT Scheme (now racket) had options available, but they weren't pretty. When I went to Common Lisp, I was first directed toward CLX, which wasn't native on Mac or Windows. Someone then suggested McClim, which still needed an X-server on Windows and now seems to be largely dead. It was then suggested that I write my own binding to WXwidgets. I considered that, but I'd then need to write a high level wrapper over those low level bindings.

Comparatively, from the little I've toyed with the Seesaw library from Clojure, it seems to be a beautiful way of handling GUIs.

Okay, I guess this comes down to another library issues.

4)Dotted pairs. The only use I've ever encountered for these is extremely fine tuning performance optimizations, but third party libraries loved surprising me with these at odd moments. I can see how Lisp-1 versus Lisp-2 might be a matter of taste, but I've never heard someone complain that how they missed dotted pairs when working in Scheme or Clojure. They may be a good argument, but I've never heard it.

5) Libraries. I'm sorry that I keep coming back to this point, but I guess it's a big one. Every time I tried to do something interesting in Common Lisp, the recommendation that I was given was to write low level wrappers to three different C libraries. For several of those projects, I found it easier to just cut out the middle man and write the whole damn thing in C. The rest of the time, I wound up writing Lisp that looked almost exactly like C.

Honestly, half of this is because I'm a mediocre programmer. I have no pretensions of greatness. If I was a great programmer, I could see how to make my own DSL that made the interaction of the libraries beautiful, instead of C with more parentheses. However, in scheme or clojure, I can usually find the work of another, better programmer, who has already made that DSL. In Common Lisp, I'm usually told to write it myself. I don't know if that's because all the other Common Lisp programmers are so brilliant that they all write DSLs all day or if it's just because they're all mediocre programmers like myself and no one knows how to do it.

6) Global variables. Every examples of idiomatic Common Lisp code I was delivered was littered with globals. This might be a stylistic decision, but it's one I've never liked. A third of my problems seemed to be solved by setting OPEN-NETWORK-SOCKET-AND-SET-FIRE-TO-PRINTER to 1 and STOP-PRINTER-FIRE to nil. I can see this reliance on globals if you're writing servers, where you have a long running application with lots of state, but I wasn't, so it just made the code harder to reason about.

7)Image based programming. I understand from the SmallTalkers that this is the best way to write code, but I don't get it. What always happened for me was that some global SWITCH-CHARACTER-ENCODING-TO-EBCDIC would get set at some point and all my code would now fail. With a file based language, I'd exit and restart to kill this accidental state and everything would be okay. With the image based code, I'd have to go through the assorted globals and find which one had changed.