>>12
Don't diss CL's standardization, it helped lisp survive, during those times there was a much smaller userbase than today(which is still small), and there were many dialects, some better than others. The standardization unified most of these dialects and ensured lisp's survival (the main reason it was standardized, was that it was a pain to port stuff between different lisps). The resulting standard was pretty complete, but not entirely set in stone, so CL implementors still had some choices. I can only see it as a good thing, try reading the Hyperspec to see how thoroughly thought out the library is.
It may not mean much for purely functional programmers, but CL's functions are first-class: they are objects which can be passed as parameters to functions and returned as needed, and the same applies to closures or lambdas. It allows programming in a fully functional style, but it's a multi-paradigm language which allows you to program in other styles as well, such as imperative, declarative, object-oriented, aspect-oriented, and so on. CL encourages using the most natural style for solving your problem, whatever that style is, maybe that irks some some Haskell programmers that are not used to being allowed such freedoms?