Very good stuff, but note that it's from 2001.<p>(Kent Pitman was involved in the ANSI CL standardization process, was the lead author for the standard itself, and created the HyperSpec -- <a href="http://www.lispworks.com/documentation/HyperSpec/Front/index.htm" rel="nofollow">http://www.lispworks.com/documentation/HyperSpec/Front/index...</a> -- which is possibly the best programming language standard document ever.)
KMP's answers to the Slashdot questions were very long, so they split them into two parts. There doesn't appear to be a link from the first part (which is the thing linked here) to the second part, so here is one: <a href="http://developers.slashdot.org/article.pl?sid=01/11/13/0420226" rel="nofollow">http://developers.slashdot.org/article.pl?sid=01/11/13/04202...</a>
The questions from people that have obviously never used Lisp haven't changed in 50 years.. "Why all the parenthesis" "Lisp is too arcane" etc. I can't be too hard on them, I used to think the same thing. But once you make a commitment to actually learn the language (just like any other language), you find a beautiful language that allows you to write very compact code with a minimum of boilerplate.<p>I'm constantly amazed at how many ideas that Lisp came up with years ago that are just now starting to gain wider acceptance in more mainstream languages. It's unfortunate that superficial complaints about syntax prevent so many developers from giving this language a chance.
I've always very much admired the elegant simplicity of Lisp and Scheme. I've done a bit of CL and, lately, Clojure hacking and I do think that learning Lisp is an enlightenment that no good programmer should deny himself.<p>However, I'm also less and less convinced that the one really killer feature that Lisp allows, macros, really makes up for the downsides of the s-expr syntax. Modern languages with closures and first-class functions and easy, powerful metaprogramming facilities give you enough flexibility without macros and history has shown that s-expr prefix notation is just not something that many people enjoy.<p>A previous poster's claim that Lisp makes a good extension language because it's scriptable is a good case in point. Dealing with the s-expr syntax in a capable editor like Emacs isn't a problem but entering complex, ad-hoc s-expr expressions on a command line is just gross. I'd <i>much</i> rather use something like Python or Ruby or Lua for that purpose.<p>I'm not sure that any of the existing statically typed, type inferencing languages have really found the sweet spot yet but, as much as I enjoy the current crop of dynamic languages, I'm still much more inclined to believe that the next step in the evolution of highly productive languages is going to involve reintroducing static typing in a less cumbersome way, not revisiting the Lisp paradigm in a new context. When I look at the work that the Rails 3 team is doing to clean up and modularize the Rails internals I just have to think that their task would be much easier in a language with explicit, static support for interfaces.
<i>Further, the package system is missing certain kinds of inheritance capabilities I've often wished for, but I recently sat down and did the work of writing my own versions of defpackage for my own use, adding the capabilities I wanted in a way that my own tools can use, and I had no difficulty.</i><p>A tendency of all Lisp gurus is to shrug off the lack of any facility that they can easily write themselves. Where is this new defpackage? Is it documented? Does it work for anybody else's needs, or just his? Is it even available? The fact that he considered these issues to be not worth mentioning in the context of the question is really frustrating.<p><i>For the most part, I've found the limitations of Common Lisp's abstraction capabilites to be incidental, and not deep, and I've found its syntactic reorganization capabilities more than capable of making up for it.</i><p>For most development there's no level of language power that makes up for being able to build 95% of your environment and 90% of your code by downloading tools and libraries used by thousands of other people, instead of (say) 80% and 70%.