It's a seamless dynamic programming language, which can, with care, be given excellent performance and a high level of abstraction. In my opinion, it's miles better than the other dynamic languages out there, by nearly every factor. It rewards investment and development very well; it's a tool for mastery, not for quick and easy starting.
If you're looking for statically typed languages, it's not going to win there. But my experience writing a lot of Perl and Python, with a certain amount of helping with Clojure and Ruby experience, strongly indicates that Common Lisp is very very competitive there outside of the 'library' front.
The Common Lisp library ecosystem isn't as polished as it is in Python from what I know. Nor is the documentation for many libraries up to scratch, even the stellar ones. Some libraries merely document the functions provided and don't go into how to use the library. Even stellar libraries such as Hunchentoot do this, which I find rather annoying after using Python libraries which seem to make it an important point to tell you how to use things.
I love CL and the idea of Lisp in general, but its modern unpopularity makes it hard to ask questions (because chances are you won't get a response any time soon) and the library situation is a real downer.
The CL community tends to expect you to read the source. You're not just a user, you're a programmer too - and quite possibly of the library you want to use.
It's an interesting dynamic, very alien to modern computing modalities.
Sometimes I get the feeling that the lack of CL libraries is somewhat self-imposed. "We don't need no stinking libraries. Since CL is so AWESOME, a competent CL programmer can reimplement whatever he needs in a fraction of the time that programmers using a lesser language would need even with the help of ready-made libraries". See "smug Lisp weenie".
Not saying that the above is actually factually true; certainly quicklisp has done a lot to make 3rd party libraries a lot more approachable.
I'm not an experienced web/http developer, but it [1] seems pretty understandable and even contains "Your own webserver (the easy teen-age New York version)" section for those who don't care, give them teh routez guys. define-easy-handler serves exactly that purpose.
From what I'm able to recall from my childhood, all docs were like that.
That feeling may be the result of some questionable syntactic design decisions in Clojure.
Hickey went over Lisp syntax and tried to remove parentheses wherever possible. (It was the hip thing, PG's Arc did it, too, which may be where Hickey got it from.) As a result, you get a sub-par editing experience —generic sexp-based structure editing doesn't get you as far as with a Lisp— and diminished readability once you get above three omitted pairs of parentheses in a row.
On the other hand, Clojure arbitrarily mandates a secondary kind of list literal in some places of the syntax, again making Clojure harder to write and edit. I don't even see a readability benefit, but of course YMMV.
TL;DR: Clojure syntax is a "complected" derivative of Lisp :-)
> you get a sub-par editing experience [in Clojure]
Paredit and vim-sexp have no problem doing structural editing. I don't use it myself, but Parinfer was created with Clojure in mind and people seem incredibly happy with it.
> diminished readability [in Clojure]
If you watched the talk that you lifted "complected" from, you'd know that this is subjective. Is German unreadable because I don't know German?
> Clojure syntax is a "complected" derivative of Lisp :-)
Complected in some ways sure, but far less so than many lisps, and certainly less so than Common Lisp. It seems your familiarity is complected with your reasoning.
Common Lisp has a sequence type that includes lists and vectors (and because strings are vectors, strings). Ordinary functions like sort, remove, find, reverse, and length operate on them.
Clojure's seq extends the abstraction to include maps and sets and other types implementing the interface.
There are some other practical answers here so I'll take a different angle.
Fun! CL is a language to play in, after a day of wrangling Java & ObjC issues I love settling down to just play in an environment that lets blast some code out and play with ideas. Of course this applies to other languages too and this is dependent on your interests, so the case I want to put out there is:
Even if a language isn't suitable for your current business needs, see if it gives you joy. Languages have trades offs to meet their goals, evaluate languages for pleasure too.
Also come visit #lispgames on freenode sometime..most of us are procrastinating making engines but it's always nice to have new folks around.
You're right that these arguments apply to many languages, but they're not tautological or nonsensical and the choice of Lisp (like many other choices) can be defended.
1. Because I was forced to? That's not why I'd want to.
2. Examples?
3. Fair enough. Though AlexCoventry's question probably shows that he does not (currently) like Common Lisp, so this answer doesn't give him a reason.
4. Sure, that's true for every language and tool. Choose it when it helps you, don't when it doesn't. But why would CL help me more than another language?
Better exception handling (conditions and restarts), advanced OOP capabilities, proper macros which are convenient to use (pretty much requires a language to be homoiconic), image-based development with ability to hot-swap any code in a running program, including but not limited to full class redefinitions without losing data. All that with resulting code able to achieve close-to-C++ performance thanks to very good (commercial and open-source) compilers. Not to mention the stability of the language thanks to the ANSI standard.
> 1. Because I was forced to? That's not why I'd want to.
You might find it pleasant. Who knows? Maybe you're a professional and you'd want to understand CL so that you can embrace and extend the system you've inherited.
> Examples?
Conditions and restarts. Incremental compilation. CLOS. Numerics.
> 4. Sure, that's true for every language and tool. Choose it when it helps you, don't when it doesn't. But why would CL help me more than another language?
CL is more like a system than a compile-and-run language. The compiler, debugger, standard library, and platform libraries all live in the image. You build the program as you go, incrementally, and can inspect it while it is running.
An error doesn't halt the entire process... instead condition handlers can either choose a restart (including asking the user what to do) and the execution continues. That's where you can attach to a remote image running on a server, notice that there's an error with a particular request, inspect the entire stack, fix the problem, and continue the request. No need to crash or anything like that. If a more hands-off approach is necessary then a handler can be written to choose an appropriate restart.
CLOS is great. You can change the class definition in a running image and the instances will incrementally update without recompiling and restarting the program (and rebuilding all of that state).
You can develop the language you need with these tools instead of using the language you've chosen (or inherited). Need an interactive prover? Try ACL2. Experimenting with sequent calculus? Want a language built around recursive fractals?
This is a question that has been answered many times over the years. Search for "why common lisp" and you'll get a long list of them.
The answers now, IMO, are not substantially different than they were, say, ten years ago. The big differences, I think, are the new competitors in the LISP world: the rise of Clojure, and the rebranding and further development of PLT Scheme as Racket.
