ithrow

I readily admit, though, that not all software development needs to be flexible and big-application focused. To that end there are many things Common Lisp is not so good at. Common Lisp is not good at being pretty out-of-the-box, it's not good at minimalism, and it's not good at prescriptive or dogmatic programming styles. I've personally not been convinced of the various approaches to using Common Lisp as a scripting language (especially because of standard multi-stage execution). Common Lisp also has an unusual learning curve: there's an initial hump of learning Lisp's oddities (DEFVAR/DEFPARAMETER, CAR/FIRST, no hash table syntax, lots of EQ[UA]L-ity functions, systems vs packages, LOOP/DO/DOTIMES/DOLIST, "Neo, there are no lists in Lisp", ...), followed by a longer path of soaking in the extensive facilities offered by the language. There's just... a lot of content. And in part because of its idiosyncratic nature, no singular approach to learning it works for everyone.

Common Lisp is pretty anemic when it comes to extreme use of functional programming. It's wholly capable and serviceable, but most library writers don't go whole-hog with FP, and Common Lisp by default makes FP a little stuffy (it requires functions bound to variables to be called with FUNCALL, and it requires defined functions to be referenced with #' syntax). There is very little support for functional data structures; the FSET library seems to be what most people suggest.