I have dabbled in Common Lisp over the years and am quite comfortable with it. I know nothing about Clojure. What are the problems with Clojure? I am just curious. Thanks!
I prefer loop/recur to TCO. You know exactly when you are, and are not, in tail position (which can be a bit obscure) and the compiler won't let you recur from non-tail.
In addition to the other problems described, Clojure just breaks the value of Lisp's syntax. Common Lisp does have its irregularities but code littered with Java imports and square brackets might as well just use C formatting and be done with it.
The primary value, to me of Lisp syntax is that code is represented as data structure literals which can be manipulated as easily as any other data structure prior to execution. Clojure has that; it just comes with literals for a few more data structures and uses two of them, vectors and maps in the syntax of built-in forms.
I think the motivation for making the sequence of arguments in function/macro definitions vectors instead of lists was primarily syntactic - to make them look different from the body. They're definitely vectors internally though.
To add to what @macco said: No reader macros. Apparently this extraordinarily powerful tool violates a religious principle with the inventor Rich Hickey.
If it was powerful enough to warrant use, someone would hack it onto tools.reader. It's obvious where it would go. For some reason, nobody has bothered with this. Likely because the reader already has programmable data (via tagged literals) and anything beyond that results maintaining your own special reader.
I haven't yet encountered somewhere that I'd have used reader macros for that wasn't better solved by using data literals or tagged literals. There might be some random place where I need syntax beyond clojure's data literals, but I'm far more likely to use a combination of data literals + tags. If absolutely required (it hasn't been yet in 5 years of daily production usage), I could simulate custom grammar using clj-antlr and a macro. If, for some unknown reason, I needed a custom non-sexp grammar embedded in my lisp that I wanted to serialize exactly and then read back in the same syntax (probably because I hate myself and/or my team), I could hack it tools.reader.
tldr; you have reader macros if you want them. Nobody wants them who uses Clojure day to day. If they did want them, they could trivially extend tools.reader themselves.
Virtually nothing requires reader macros. That doesn't mean they aren't useful.
Personally if I wanted reader macros in clojure I wouldn't bother implementing them because it wouldn't be worth the pain to me. However, if clojure had them I/libraries would likely make good use of them.
It has a reader as a library. It's entirely possible for you to change its lookup map to a defmethod and go to town altering s-expressions for arbitrary syntax if you wish. You're not hacking a new reader here, you'd refactoring something that probably should have been a generic method to begin with into one. Nobody has bothered with this because it's not useful to anyone, as far as I can tell. People who want non-data syntax write it with clj-antlr/instaparse (which are very easy to use) and use a macro when they want to interleave it into their code. These universally end up with a data-based AST that is readable and printable.
If you know Common Lisp reasonably, you'll probably have some insight into Clojure, e.g. Leiningen is a system definition facility; seq is an extension of sequences; and multimethods are generics much like methods. I'd say Clojure stands on the shoulders of giants.
There are some Lispy things that Clojure does out of the box that are more Lispy than than Common Lisp does out of the box, e.g. lists and other seq's as functions in the function position of an x-expression. There are things Clojure will not do such as reader macros. Clojure's syntax is a bit different, but generally reads cleaner in the same way one might say a font reads cleaner. YMMV.
> lists and other seq's as functions in the function position of an x-expression.
Makes code more difficult to read. I consider this a language design error. I had that on the Lisp Machine 30 years ago (example callable arrays, ... - maybe even Maclisp in the 70s had it), few people used it and it did not make it into Common Lisp.
Common Lisp was designed such that for the programmer and for the compiler the first element of a Lisp form is easily recognisable as a function: it has to be a symbol naming a function or an actual lambda expression.
Pays back it code maintenance over time...
> but generally reads cleaner in the same way one might say a font reads cleaner.
I think it reads cleaner in the way PERL code is read cleaner.
Personally, I find code easier or harder to read in the same ways I find prose easier or harder to read -- it depends on the author's ability to tell a story and the story the author is trying to tell and my interest in hearing the telling.
Seq's as functions are sometimes more readable to me for the same reasons code that uses reader macros may be more readable to me (even though reader macros may do away with normal s-expression syntax entirely). But again, mileage varies.