Common Lisp is not a purely functional language.<p>The most caracteristic feature of Lisp in general is that, its whole syntax is the literal representation of one of it&#x27;s core datatypes, the linked list.  This allows for creating idioms of arbitrary complexity and reusable abstractions with ease, one a tiny kernel.<p>Another wording of this is that the Lisp family of languages represent their programs as data that those programs <i>directly</i> manipulate, and thus, programs can manipulate themselves.  This is <i>homoiconicity</i>.<p>For who likes laconicisms, Lisp is a pleasant way to write and execute a parse tree.<p>The advantage to this is that you can create syntactic abstractions that fit in nicely, that work on structured data instead of strings not parsed and verified yet (hey CPP!) and are reusable by other abstractions.<p>The disadvantage is that your set of abstractions can become very easily dialects, and the language ecosystem is prone to (and damned by) fragmentation (i.e. every Scheme has it&#x27;s own module system, and then there&#x27;s a late standard that nobody uses).<p>Another advantage of Lisp, though not unique to it neither theoretically nor practically, is the <i>image</i>, that is, the state of the interpreter.  Your average Lisp process is code running on a Lisp VM, and the VM allows you to modify the running code.  This allows you to pause the thread when an exception happens, modify the code, and <i>play</i> it again, and the program uses the new, modified version of the code.  These are called <i>restarts</i> and supported at least in Steel Bank Common Lisp, and are well integrated into SLIME, the canonical Emacs mode for Common Lisp and other uncommon (!) lisps.  This is so powerfull, I read that in one space mission, when they spotted a bug in the code of a research apparatus already in space, they connected to its image and hotpatched the code fixing the bug, saving NASA millions of dollars.