在reddit interview with Peter Norvig，他说
“出于各种原因，这套网络 库和协议较慢 在LISP中发展比在其他方面发展 语言”
因此，网络社区中的lisp采用率下降，人们追求更丰富的图书馆集。
LISP社区在构建Web框架时是否存在这种缓慢的原因？
答案 0 :(得分：11)
先生。在我看来，Norvig的评论比对当前形势的评估更具历史意义。也许在90年代中后期，网络相关的库在Common Lisp中的表现并不像在Java等其他语言中那样快。
但今天肯定不是这样。我可以命名不下五个Common Lisp Web服务器（CL-HTTP，Hunchentoot，S-HTTP-Server，Araneida，AllegroServe），更不用说Apache的mod-lisp了。必须有近十几种不同的Web框架（KPAX，Weblocks，UncommonWeb等）。每个网页首字母缩略词都有常见的lisp库，可以命名为：SOAP，XML，XLST，FTP，XML-RPC，S3，AJAX .... ad infinitum。还有一些工具在其他语言中没有模拟，比如ParenScript奇迹。
请参阅Common Lisp目录，查看网页库的大量列表：http://www.cl-user.net，其中许多都维护在http://www.common-lisp.net
答案 1 :(得分：8)
我认为在Lisp中开发库比使用其他语言慢一点的主要原因是它太简单了。用Lisp编写的库通常不值得这个名字。它们只是几行代码，特定于手头的任务。一些额外的分钟会产生一个通用的库，但是当它只是一些简单的代码行时似乎没有人会想要它。
大约一年前，我不得不在Clojure中读写CSV。标准建议是使用几个着名的，经过良好测试的Java库中的任何一个。我发现识别哪个库最合适并且学习它的API比在Clojure中简单地write my own更难。这是50行，它可以很好地处理我的用例。但它并不是一个好的CSV库;有很多案例它不支持，所以我没有把它打包成一个库，把它放在Clojars之类的。我想我是问题的一部分。
今天网上最近的一半实用Lisp教程包括一个HTML生成宏的例子。其中大部分都是生产质量的，而不仅仅是一大堆代码。这似乎不值得打包并打电话给图书馆;这是一个琐碎的代码，任何体面的Lisp程序员都可以在几分钟内编写。 当然值得打包成一个库，Edi Weitz已经发布了一堆代码。
答案 2 :(得分：5)
我不知道他的意思。我的猜测是，它可能主要只是一个更普遍的“缺乏Common Lisp库”投诉的实例（我发现它主要是无聊的，但无论如何）。
对note that感兴趣：
第一个符合HTTP 1.1的服务器和W3C使用的[one] 调试HTTP 1.1参考实现
是用Lisp编写的。
答案 3 :(得分：2)