tags:

views:

224

answers:

5

In the reddit interview with Peter Norvig, he says

“For various reasons the set of web libraries and protocols were slower to develop in LISP than in other languages”

and consequently lisp adoption among the web community went down, and people went after languages with richer library sets.

Is there a reason for this slowness in the building up the web frameworks by the LISP community?

+3  A: 

I don't know what he means. My guess is it's probably mostly just an instance of the the more generic "lack of Common Lisp libraries" complaint (which I find to be mostly bunk, but whatever).

It's interesting to note that:

the first HTTP 1.1 compliant server and [the one] used by the W3C to debug the HTTP 1.1 reference implementation

was written in Lisp.

Ken
+1  A: 

"Lisp community" seems a broad term. But for Common Lisp you have Hunchentoot which a lot of people use. Dr. Scheme ships with web facilities built in.

My favorite, Clojure has many cool actively developed libraries for building web applications, Ring, Compojure, Enlive, Clutch, to name just a few that are interesting.

dnolen
Hunchentoot is great, but it's based on TBNL and inspired by Aserve, whose earliest changelog entry is 1999. In comparison, AOLserver (nee NaviServer) was using C/Tcl in 1994. Perl, Java, and PHP folks were also putting things on the web in the mid-1990's. Clojure didn't arrive on the scene until 2007. I think that meets the criteria for "slower to develop". :-)
Ken
A: 

According to the quote, there is not only a reason, there are various ones.

jsn
That was a joke! My poor reputation score.
jsn
+4  A: 

Mr. Norvig's remark seemed to me to be more historical than an assessment of the current situation. Perhaps in the mid to late 90s web related libraries didn't appear as quickly in Common Lisp as they did in other languages like Java.

But certainly today that is not the case. I can name no less than five Common Lisp web servers off the top of my head (CL-HTTP, Hunchentoot, S-HTTP-Server, Araneida, AllegroServe), not to mention mod-lisp for Apache. There must be nearly a dozen different web frameworks (KPAX, Weblocks, UncommonWeb, et al). And there are common lisp libraries for every web acronym you can name: SOAP, XML, XLST, FTP, XML-RPC, S3, AJAX.... ad infinitum. And there are tools that have no analog in other languages, like the wonder of wonders ParenScript.

See the Common Lisp Directory for a fat list of web libraries: http://www.cl-user.net , many of which are maintained at http://www.common-lisp.net

Chris Perkins
+3  A: 

I think a major reason libraries can be a bit slower to develop in Lisp than in many other languages is that it's simply too easy. Libraries written in Lisp often don't feel worthy of the name. They're just a few lines of code, and specific to the task at hand. A few extra minutes would result in a general-purpose library, but it doesn't seem like anybody would want it when it's just a few trivial lines of code.

About a year ago, I had to read and write CSV in Clojure. The standard advice was to use any of several well-known, well-tested Java libraries. I found it more difficult to identify which library was most appropriate and learn its API than it was to simply write my own in Clojure. It's 50 lines, and it handles my intended use case beautifully. It's not exactly a good CSV library though; there are plenty of cases it doesn't support, so I haven't packaged it up as a library, put it on Clojars or the like. I suppose I am part of the problem.

Half the recent practical Lisp tutorials on the web today include an example of an HTML generation macro. Most of those are production-quality and little more than a screenfull of code. That hardly seems worth packaging up and calling a library; it's trivial code any decent Lisp programmer could write in a few minutes. It is of course worth packaging up as a library, and Edi Weitz has released a bunch of code along those lines.

Zak