| I'll take a small stab at giving a satisfactory answer. Some of these apply to all Lisps, some don't apply to different Lisps, for varying reasons of implementation. There are two basic reasons for learning a language - personal growth and for creating a product.
In the realm of 'personal growth', Lisp opens the doors in your mind to working with macros and homoiconic code. It also shares with other dynamic languages the features of closures, currying, and the usual benefits of first-class functions. Scheme (as opposed to Common Lisp) has continuations, which are very powerful. These are all features that open the mind to new ways of thinking, hopefully for the better. In the realm of the pragmatic - Lisp- unlike other modern dynamic languages I know of ( I think Smalltalk can do this)- maintains an ability to version running objects in a system. It can perform hot-swapping of code remotely without bringing the run-time down. I haven't delved into this deeply yet, but I plan to later on. I believe Erlang is the only other major language that can hotswap well. Further, unlike the other mainstream dynamicaly typed languages going (Ruby, Perl, Python), Common Lisp can compile functions directly to native code. You will find SBCL is one of the best dynamic language contenders on the Alioth Shootout. (I'm not sure how Haskell and OCamls classify - I think they might generate binaries). Therefore, Lisp is a good candidate for code that requires 'relatively' good performance, but isn't worth taking the time to do in C++. The commercial Lisp implementations have GUIs that are supposed to work seamlessly on any of the 3 major OSs. That's a major feature in my book. Lisp is famous for its ability to be expressive via its macro facility and the regular notation. So if you have a problem which your language is fighting you with - maybe you should find Lisp and check it out. I've done some small work with a Lisp program that dynamically created random functions and then mucked with them on the fly in an optimization effort. It was, bluntly put, trivial to do the meta-function work. The chief difficulty was the actual algorithm (and my inexperience with Lisp. :-) ). In regards to basic Lisp data storage, it is analogous to JSON's relationship with Javascript: really easy. So to move this from a boostering to an engineering post, I'd like to consider some of the cons of Lisp. Con 1 is the tooling. It's not as flashy as Java's or C#'s. If you need your IDE and refactoring tools, it's not going to fly for you. Personally, I just hang out in emacs for all development, so it's water off a duck's butt to me. :-) Con 2 is the wreck of library finding. Quicklisp moved us into the 2010s with its release: it's on par or better than, say, cpan or gem. But there are still tons of libraries floating out there with crufty code that MAY be useful. This goes along with the ability of Lispers to write the same utility over and over again. Or, worse, have the same name for multiple libraries (clon for instance). I think that the library situation is getting way better though thanks to Xach. Con 3 is the system integration. Like Python/Perl/Ruby, directly integrating into system calls is not trivial in the core language. This is massively different from C# or C++, where a system function just an using or an #include away. Common Lisp does have a solid foreign function interface from what I understand. I haven't used it yet though. Con 4 is the lack of ability to run on super-low memory systems easily. Usually a Scheme-Lisp can be crammed in (I know of one that's been put on a system with 64K of memory). But I'm not convinced anything but C or ASM is the right tool for this job. Con 5 is, let's face it, the weird. Continuations. Closures. Unrestricted lambdas. Macros. Parentheses. It's not Python/C++. I'm not saying Lisp is the Uber-Language, the Ultimate Language From Which We All Go To (although historically, the ur-Lisp is the primordial ancestor of all dynamic languages from what I can tell). What I am saying is that it is a respectable general purpose language. |
Lisp's convenient format for data was a HUGE win, for a while, but other languages have caught up. Python has dicts, Lua has tables, Javascript has JSON, ML has its variant types, Erlang inherited Prolog's terms (its parallel to Lisp's s-expressions), etc. All of the above are extremely useful. Expressive data and simple code is far easier to maintain than overly simple data and compensatingly elaborate code. Languages without a good high-level format for structured data either lose out on a lot of functionality, or (sigh) fall back on XML.
Also, Quicklisp is quite nice, and props to Xach for setting it in motion.