If you believe that standards are helpful, then surely one standard reader behaviour is a good thing?
Regular macros are a different issue: they allow creation of custom control structures that aren't possible with normal functions. That's a powerful and useful feature, as many Lisps have proved over the years.
So Clojure rejects the former (unnecessary syntax sugar, potential for confusion, dubious value of reader proliferation) and accepts the latter (additional semantic power, proven utility). I personally think that's a good trade-off. YMMV of course.
Of course, there's nothing stopping you from implementing a custom reader in Clojure if you really want reader macros. So far, nobody (to my knowledge) seems to have cared enough to do this.
NOTE: I'm not bashing Common Lisp: just pointing out that language design has real trade-offs. For me, Clojure gets the majority of these design decisions right. For others, maybe reader macros are an essential feature and Clojure therefore doesn't work. No problem, use whatever works for you.
Btw., vectors are written as #(1 2 3) in Common Lisp.
Thus if I as a developer want to serialize my data structure to an s-expression, I can use reader macros.
New data type syntaxes does not make code much harder to read.
> If you believe that standards are helpful, then surely one standard reader behaviour is a good thing?
Sure, Common Lisp has a standard reader. An extensible one.
> Regular macros are a different issue: they allow creation of custom control structures that aren't possible with normal functions. That's a powerful and useful feature, as many Lisps have proved over the years.
Custom control structures don't make the code harder to understand? Strange.
> For me, Clojure gets the majority of these design decisions right.
For me many of these Clojure design decisions look arbitrary and some I find just wrong. But that's just me.
Really?
Name them.
Granted, I'm not sure myself, since I left the community in the fall of 1984 when I left Goldhill (which ran on 16 bit x86 and 640KiB - minus what DOS extra took up, so not only did it not do threading, it didn't even (initially, while I was there) do lexical scoping (!)). But I heard it took some time for Symbolics to adopt Common Lisp (installed base problem), and I don't know about the other early commercial ones.
Allegro Common Lisp is rather early to have had threading on the PC platform. Did the Macintosh do threading as of 1987? What about Lucid? A quick look at the indexes of the users guides for Liquid Common Lisp, which I understand to be its current version, don't have the word thread in them.
Liquid Common Lisp? The chapter on 'multitasking' is hard to find?
http://www.lispworks.com/documentation/lcl50/aug/aug-103.htm...
Threads are in Common Lisp usually called Processes. The Lisp Machine had them and basically the same API was used in Common Lisp implementations. Allegro CL, Lucid, LispWorks, ...
The entry points have been literally for decades functions like PROCESS-RUN-FUNCTION and MAKE-PROCESS.
> Did the Macintosh do threading as of 1987?
The Macintosh OS at that time did cooperative multitasking. It was supported by Macintosh Common Lisp. Macintosh Common Lisp supported what was possible and the old Mac OS was crippled.
Symbolics had little problem providing Common Lisp. The Symbolics Lisp Machine ran Common Lisp and ZetaLisp side by side in one Lisp. Of course you could call the scheduler functionality from within Common Lisp. Since Symbolics also developed a new scheduler, I guess the new one was written Common Lisp.
My knowledge is pretty much limited to the free Common Lisp implementations, since I never had a budget for a commercial one, and their threading story has not been so happy. But that's not a valid criticism of Common Lisp.
Threads in ECL:
http://ecls.sourceforge.net/new-manual/ch27.html
Threads in Clozure CL:
http://ccl.clozure.com/manual/chapter7.html#Programming-with...
Threads in SBCL:
http://www.sbcl.org/manual/index.html#Threading
ABCL support threads.
Threads in CLISP:
Clojure is basically just one real implementation.
Clojure limiting the use of reader macros is just another example where somebody is telling me how I should use a language. It's basically as in Java. Common Lisp and Lisp in generally has favor a different root: give power to the user. Why stop there. Why not provide a fixed amount of macros and remove the user-written macro facility from the language.