I'm an amateur LISP hacker and not an expert, and I hope this thread doesn't turn into a flame war, but I can say that LISP is excellent for symbolic computations (a la lambda calculus, which Turing proved was equivalent to a Turing Machine) [1].
If you're more familiar with C languages, I like to think of LISP as the C of symbolic languages. It has practically no syntax, and LISP (as it exists today) has the neat feature that it's data structures are the same as its programs. Writing LISP code that modifies and generates other LISP code is relatively simple compared to doing the same in a syntax-rich language.
LISP does all of this at its lowest level, just like how C manipulates the fundamental elements of a CPU (pointers, contiguous memory blocks, basic arithmetic / logic operations, etc). The way CPU's are designed revolves around the Von Neumann Architecture [2], and C exploits this design very well. Unfortunately, LISP doesn't quite match this architecture, so it has traditionally performed poorly compared to C. But CPU's could certainly be designed to operate around a LISP-like model[3], so the Von Neumann paradigm isn't the only way.
> Unfortunately, LISP doesn't quite match [the Von Neumann] architecture, so it has traditionally performed poorly compared to C.
Exactly. It has traditionally performed poorly compared to C, but this hasn't been the case for a lot of time. There's a number of misconceptions about what is and what is not a lisp.
First of all, a lisp doesn't have to be interpreted or run in a virtual machine. While this is true for a lot of lisps, Common Lisp performs what you could call just-in-time compilation: you can even inspect the compiled code of a function by calling the `disassemble' macro on it, and optimize it based on the disassembly.
A lisp doesn't have to be dynamically typed. There are many examples of statically typed lisps (Shen, Dylan, Typed Racket, Lux), and in other dynamically typed lisps such as Common Lisp you can add type annotations as needed to optimize functions.
A lisp doesn't have to be garbage collected. It certainly is more convenient to have GC when you have such a dynamic language or want to program in a functional style; however, this is not required. Carp and GOAL[0] do not use garbage collection, and in Common Lisp you can generally give hints to the garbage collector to to make it run where you need it to.
A lisp doesn't have to be functional! While lisps usually advocate a functional style to varying degrees (mutation in Scheme is usually marked with a ! in the name of the function (set!) but normally discouraged, Clojure is immutable by default IIRC), but very few are purely functional (only Lux comes to mind) and most are in fact very procedural (Common Lisp).
Finally, Common Lisp has been designed to also be used as a systems language, and thus benefits from many optimizations targeting the Von Neumann architecture that can make it just as fast, if not faster, than C.
This is a good post detailing some of the optimizations that you can perform in Common Lisp:
To answer 0wl3x's question, lisps can be used for just about anything; it's just a family of homoiconic languages that generally make heavy use of macros as fundamental abstractions.
If you're more familiar with C languages, I like to think of LISP as the C of symbolic languages. It has practically no syntax, and LISP (as it exists today) has the neat feature that it's data structures are the same as its programs. Writing LISP code that modifies and generates other LISP code is relatively simple compared to doing the same in a syntax-rich language.
LISP does all of this at its lowest level, just like how C manipulates the fundamental elements of a CPU (pointers, contiguous memory blocks, basic arithmetic / logic operations, etc). The way CPU's are designed revolves around the Von Neumann Architecture [2], and C exploits this design very well. Unfortunately, LISP doesn't quite match this architecture, so it has traditionally performed poorly compared to C. But CPU's could certainly be designed to operate around a LISP-like model[3], so the Von Neumann paradigm isn't the only way.
[1] https://en.wikipedia.org/wiki/Lisp_(programming_language)
[2] https://en.wikipedia.org/wiki/Von_Neumann_architecture
[3] https://en.wikipedia.org/wiki/Lisp_machine