Read SICP, Practical Common Lisp (+On Lisp, AMOP, CTLTL2, PAIP, Hyperspec, ...).
How much is it used? It's not the most popular language, but has good and well-maintained implementations and lots of libraries, which means it's suitable for most general purpose programming, and once you're familiar with it, it tends to be easier to do complex things in it ``the right way'' (as opposed to quick hacks, although you can also do that if you wanted). There's also high-performance implementations which means that not only you get performance, but also minimizes the time it takes to write your code (an advantage similar to that given by scripting languages, but without the speed penalty).
Name:
Anonymous2012-01-19 6:39
Why should one choose lisp anyway?
What are its advantages?
>>4
Very good metaprogramming support and just about everything in the language is user definable/controllable, be it syntax, semantics, the OO system, ... . Good default language features. Support for many different programming paradigms. Decent performance. Structural editing. Allows for fairly rapid development cycles - no compile/run/... - you can compile functions as you write them and redefine just about anything.
In my case I found that it matches pretty well with my mental model of the program I'm trying to write and it takes me much less time to write my code, and less time to debug it. When I want to do something which isn't directly supported by the language, I don't have to feel like I'm fitting a square peg in a round hole by using some boilerplate-like design pattern - I can just quickly implement the language feature that I feel is missing with little effort.
Name:
Anonymous2012-01-19 8:13
>>2
How is ruby better? Same program written in CL runs 10 times faster than in ruby.
>>8
Read the AMOP (Art of the Meta-Object Protocol).
AMOP shows how CLOS can be implemented in itself using a MOP - in a metacircular manner.
The MOP lets you define object systems like CLOS, or to extend CLOS in many ways beyond those specified by the ANSI CL standard. The MOP is supported by most major implementations and it tends to be the exposed interface to CLOS' internals (it has a standard document and there is even a compatibility layer (closer mop) that makes sure you get the same interface across all implementations), but it should not be treated just as something on top of CLOS: it's something on top which CLOS itself is based, and you can build any OO system that you'd want on top of it, or greatly customize CLOS (which itself is one of the most advanced OO systems out there, as far as features go).
Much of MOP's functionality centers around reflection support: you have meta-objects representing classes and generic methods and well-defined interfaces for accessing or changing them. The book not only shows how CLOS can be defined in itself, but also shows how a CL without CLOS could be extended to support it (this was true for '80's CLs). The "toy" implementation of CLOS+MOP presented in the book is called Closette, while most modern CL implementations tend to use modified versions of the more heavy-weight (and more optimized) PCL(PortableCommonLOOPS) - they are related in both design and implementation and originate from the same source: Xerox Corp (both are MIT-like/nearly public domain licensed).
Name:
Anonymous2012-01-19 13:38
>>9
I wonder how far I can go on simplifying it without losing all of the power. It seems to me as if (create-object (<classes>*) <any-value>) as well as a way to inject and inspect multimethods form such a subset. I don't know. Your thoughts on this?