On more than one occation when writing web code I found myself in the debugger in the middle of a request handler. The browser just sits there waiting for a response. I found the bug and restarted the handler before the browser time-outed. The browser recieved the response as if a bug never existed. Of course this only works if you can find and fix a bug in under 120 seconds :)

Yes, abandon something that's been making money for 30 years and throw away decades of domain expertise because it's not fashionable. Great idea.

Not that clojure is a bad language(I actually like it quite a bit), but compared to the professional common lisp world, it's a baby. CL has an extremely high-quality and stable specification, dozens of very good implementations for pretty much every platform(whit several ones that are decades old, and several ones that are brand new), a community that simply refuses to die, and use cases where clojure would be completely inadequate. Not to mention the assertion that non-clojure lisps are not going anywhere is completely false, both common lisp and racket(hell, even elisp) are growing in their niches and developing their ecosystems. Books and libraries are being written, products are being developed, conferences and meetups are organized, businesses are started and research is being done.

With zero snark, because I've never had the (apparent) pleasure of working with a lisp, what are the use cases for Common Lisp? It barely registers when talking about building APIs and production cloud platforms for game services, which is my current wheelhouse. Clojure comes up, of course...

What all of these problems have in common is that they involve crunching a fuckton (the technical term) of data, sometimes in real time, and making decisions based on it. Some of the problems are NP complete and use genetic algorithms and other techniques to approximate ideal solutions. These are extremely hard problems.

It's also worth noting that many of these systems were started in the 80s and 90s and encode a lot of research and business logic which simply isn't yet available elsewhere.

I'd love to work on one of these systems, but unfortunately I've only been working in industry a mere decade and the competition in that area has mostly 2-3 times that level of experience.

Specific domains where clojure might not do so well are probably the same domains where the JVM is impractical, for example embedded or low-level programming, anything where you have to interact heavily with the world outside of the JVM and have a small footprint.

Obviously mobile looks like an area where common lisp has better options(with this announcement that makes two commercial implementations, the other one being mocl: https://wukix.com/mocl).

If you want to write native(non-swing) guis LispWorks has that covered, and the open source gtk/qt bindings, while a bit unlispy work very well. Racket has a pretty cool framework too.

There is also the fact that a lot of programmers, rationally, or irrationally, simply dislike the JVM. Pretty much everything I dislike about clojure has more to do with the JVM than the core design itself.

Both lispworks and franz maintain success lists, so you can look at some of these projects if you want to see some areas where lisp has done fine:

My understanding (as a Lisp beginner but with 15+ years commercial development experience) is that Common Lisp has more powerful macro systems, better tooling and better error handling. Some commercial Common Lisp implementations are also known for good, portable GUI frameworks.

Clojure has better support for concurrency, very good JVM integration, and a better story around Javascript courtesy Clojurescript (vs. Common Lisp's parenscript).

While some people seem quite strongly averse to Clojure (see e.g. http://www.loper-os.org/?p=42) my opinion - again, that of a Lisp beginner - is that they both have their uses.

It's certainly possible to build web front-ends and API-based back-ends using Common Lisp. I know because I'm doing it now :)

Common Lisp hits some kind of sweet spot for developing very specialized software. If you think you need to build huge specialized software framework or special programming language from ground up to start solving the problem, you might need Common Lisp.

Common Lisp is very programmable language that can still deliver decent speed.

My favorite example would have to be CLOS the Common Lisp object system. Although it's a bit hairy in certain places, it essentially transforms a procedural/functional language into on of the most powerful object oriented languages around. Macros play a small, but crucial part of it, subverting the rules of lisp in order to add another dimension to the language.

Another great example might be Postmodern and CLSQL, both of which include SQL DSLs, much better than concatinating strings or muddling around with ORMs. CL's loop macro basically ads an algol like language to lisp(if you dislike loop, there exist lispier alternatives like iterate).

Macros take care of the case between writing a function and writing an interpreter, and with judicious use, they can help build much cleaner abstractions that give a qualitative improvement to a code base.

As a lisper, I can say that this insight is very true, but it is still just a simplification. Most lisps deal with it in different ways.

In the scheme world, the way they deal with this is by wasting a decade on making decisions about the language that should have been done in the 80s. The result is that scheme essentially split into scheme and racket. Now we have an awesome language and a nice little ecosystem thats good for teaching and research, and possibly even real work(tm). Classic scheme unfortunately is fragmented into implementations who all do things slightly differently and occupy their own niches.

In the clojure world, they have a) a BDFL who sets the course of the language. b) A very strong core community of very smart people who managed to build a nice culture based on common ideas about software and design.

In the common lisp world, because we have a very high-quality standard, implementations are almost completely compatible. Compatibility libraries make it easy to write very portable code, avoiding the scheme problem. At the same time implementations are free to experiment. The other problem of everybody developing their own little universe tends to be rare. Because common lisp is so old, we have a long history and traditions that guide future design, but don't constrict it. There is a subtle balance here. We have a lot of old examples to learn from, but we are not locked in by too many bad old decisions(not always the case, but good enough in practice).

A few examples where this does not work include utility libraries and things like json libraries, libraries for outputing html etc. Since we don't have a BDFL we are left to figure things out amongst our selves and sometimes, like with utility libraries(there are dozens such, which is ridiculus) it doesn't work. In other cases, it works very well, for example quicklisp, ASDF, bordeaux-threads, closer-mop, hunchentoot etc. are either de-facto standards, or sufficiently popular to be a very good default. As with clojure, there are a lot of common ideas about what is good design in the community, we have a lot of examples to learn from, as I mentioned.

In the end, at least in the case of common lisp and clojure, I see it as an advantage to have this "level of possible diversity", it's what has kept lisp alive for 50+ years! The fact that lisp can adopt to each new era of software development philosophy is a great reason to study it. It will be with us for many more decades because of this.

C++ is similar with regards to C code. They're compatible enough that a lot of people will write "C/C++", but they're still incompatible enough that you'll get yelled at by a lot of people if you write "C/C++".

Geiser is great, but SLIME is much better mostly because Common Lisp was designed with interactive programming in mind(the condition system, the object system, dynamic variables ect. are all features that help with interactive programming). You get an almost smalltaskesque feeling with slime.

All the major lisp dialects are rather different and encourage different styles. My own opinion is that no one is a better first lisp, as long as you check out the others eventually. Racket is an excellent start. I always advise people interested in lisp to check out racket, clojure and Common Lisp in whatever order they wish. I started with scheme in 2008, moved to clojure in 2009 and I've been a happy Common lisper since 2010/11. Depending on your own style as a programmer you might choose a different main dialect you like best, but only after you try them all :)