他说, 在对Peter Norvig的reddit采访中
"由于各种原因,在LISP中开发的网络库和协议集比在其他语言中慢"
因此,网络社区中的lisp采用率下降,人们追求更丰富的图书馆集.
LISP社区在构建Web框架时是否存在这种缓慢的原因?
在我看来,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奇迹.
有关Web库的大量列表,请参阅Common Lisp目录:http://www.cl-user.net,其中许多都在http://www.common-lisp.net上维护
我认为在Lisp中开发库比使用其他语言慢一点的主要原因是它太简单了.用Lisp编写的库通常不值得这个名字.它们只是几行代码,特定于手头的任务.一些额外的分钟会导致一个通用的库,但似乎没有人会想要它只是一些简单的代码行.
大约一年前,我不得不在Clojure中读写CSV.标准建议是使用几个着名的,经过良好测试的Java库中的任何一个.我发现更难以确定哪个库最合适并且学习它的API比在Clojure中编写自己的 API要困难得多.这是50行,它可以很好地处理我的用例.但它并不是一个好的CSV库; 有很多它不支持的情况,所以我没有把它打包成一个库,把它放在Clojars之类的东西上.我想我是问题的一部分.
今天网上最近实用的Lisp教程的一半包括一个HTML生成宏的例子.其中大部分都是生产质量的,而不仅仅是一大堆代码.这似乎不值得打包并打电话给图书馆; 这是一个琐碎的代码,任何体面的Lisp程序员都可以在几分钟内编写.这是当然值得包装起来作为一个图书馆,和艾迪韦茨已经发布了一串代码沿着这些线路.
我不知道他的意思.我的猜测是,它可能主要是更普遍的"缺乏Common Lisp库"投诉的实例(我发现它主要是下铺,但无论如何).
值得注意的是:
第一个符合HTTP 1.1的服务器和W3C用于调试HTTP 1.1参考实现的[一个]
是用Lisp写的.