I haven't actively used Common Lisp in years. But for a long time, I used it professionally. Common Lisp's greatest strength is that it's "the programmable pro

I haven't actively used Common Lisp in years. But for a long time, I used it professionally. Common Lisp's greatest strength is that it's "the programmable programming language." You can customize everything from the lexer to the syntax, and you can extensively customize or even replace the object model. It's trivial to write code that writes code. There are some limitations. Haskell, for example, is less customizable but it works very well at high levels of mathematical abstraction. Now, in practice, I don't often need the specific kinds of power that Lisp offers. Or rather, when I do need it, I don't need that power instantly at my fingertips. Completely customizing your programming language is something you should think long and hard before doing, and the median team will do it very badly. So I'm happy with the tradeoff offered by Rust macros, for example: They're harder to use than Common Lisp macros, so you only use them when you need them badly enough. Even for most above-average teams, I think it's a net win for macros to be a bit obnoxious to use. But if you ever find yourself on a small team of incredibly talented programming language designers, and you're working in a problem space where no off-the-shelf language can do what you need, then Common Lisp is well worth a hard look. Paul Graham's "On Lisp" is actually an excellent overview of the kinds of things you can do with Lisp. Norvig's first AI book is also a good demonstration of Lisp, even if the "AI" part is hopelessly obsolete at this point.