Indeed. As much as I dislike CL's quirky inelegance (I prefer the scheme side of the Lisp family tree), it's a tremendously powerful and effective language, and one of the best choices for Getting Stuff Done Right Now using Lisp. In fact, probably the best choice.
On the other hand, quoting Einstein's quote found in the famous book by Sussman and Wisdom who use Scheme to teach Classical Mechanics, "I adhered scrupulously to the precept of that brilliant theoretical physicist L. Boltzmann, according to whom matters of elegance ought be left to the tailor and to the cobbler.”
In this case, though, I think it still works. It says nothing of the work they do, but more to the goal of their work. Tailors/coblers (fashion, in general) are tasked with making elegant attire. It is true that some are tasked with making practical attire.
Physicists, however, are never tasked with making elegant physics. It is rewarded. But it is not directly their task.
quirkyness isn't good in a PL: you want your language to act the way you'd expect, and have the arg orderings, function names, etc. That way, you don't get it wrong.
[ANSI] Common Lisp may be unique among programming languages in that it is based on a standard and that standard was written to reflect how people were actually using Lisp after roughly thirty years of general use and about a decade of actual Common Lisp use.
The other thing about Lisps is that if a programmer doesn't like the order of arguments or the function names or even the parenthesis, the language lets them change whatever it is they don't like and the changed features still have first class status. That's also one of the criticisms of Lisps.
I think the specification committee for ANSI Common Lisp would have agreed that defaults matter. It's just that their criteria for defaults was "What professional programmers are doing right now".
Historically, Scheme somewhat dodged avoided issues like argument order by excluding functionality from the language spec. My experience is that once Scheme gets expanded out and becomes Racket, the many hands show up as inconsistencies among similar functions much like Common Lisp.
Clojure, to me, seems to have the right idea: procedures that abstract operations from data types...for example there is not one mapping procedure for lists and another mapping procedure for arrays. Racket seems to be headed in that direction.
In Clojure map also works on hashes and sets. In keeping with the previous discussion, there's also only one variety of map in Clojure. It's this orthogonality of operations and datatypes that I think is Clojure going in the right direction.
None of which is to say that Clojure isn't standing on the shoulders of giants.
I like the core Scheme language, but I never could get used to its macro syntax. I prefer Common Lisp macro syntax for that, and Clojure's macro system being very similar to that of Common Lisp is an added advantage!
Syntax-rules isn't great. But pretty much every scheme has recognized this, and added an imperative hygienic macro system (think Clojure's macro system, where you can't leak environment unless you want to, but better). There are three main choices at the moment: syntax-case, sc macros, and er/ir macros.
er (or explicit rename) macros are the simplest system: they're like CL macros, with a few minor differences. Also, because Scheme is a lisp-1 with a mutable global environment, you have to rename absolutely everything. Even lambda. Yes, really.
Because of this, CHICKEN (the only scheme that uses er macros) also has ir macros, which are like er macros, except that everything is implicitly renamed unless you say otherwise. However, expanding an ir macro is O(n) under the hood, which sucks. This is probably the worst part of CHICKEN, but it works well enough.
sc (syntactic closure) macros are similar to ir macros in nature, although the syntax and abstraction is different. It's a pretty nice system, currently used in Chibi and MIT scheme, and (while it's really too early to tell) seem to be the macro system most likely to make its way into R7RS-large.
Finally, there's syntax-case. It's used by racket (I think: racket's syntax-case has apparently been heavily extended) and guile, and is the R6RS macro system.
Personally, I don't like syntax-case. IMHO, it's overly complex, it throws away the standard macro abstraction for little benefit, and is generally a pain to use. But it's not objectively badly designed, and some people seem to like it (conveniently, this description, with some minimal modification, applies quite well to R6RS itself). You might be a person that likes it. I don't know. All I know is that I am not one of those people.
The second program will work in every Scheme I can think of (depending on what you want returned when the condition fails, but it shouldn't crash). I don't know what T did differently, but it's no longer the case.
