

The Zen mystique in the Lisp community - emporsteigend

The Paul Graham essay Beating the Averages (http://paulgraham.com/avg.html) contains a telling quote from the dubiously sane Eric S. Raymond:<p>"Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot."<p>Rhetoric about Lisp is often couched in the language of the arduous journey of a novice monk to Nirvana. (Perhaps Lisp advocates are the <i>bodhisattvas</i> in this narrative.)<p>I don't think this sort of quasi-religious approach is a good way of evaluating programming languages. I would prefer a more scientific, even quantitative approach.<p>Reviewing the packages available on common-lisp.net, one notices that most of them, in fact the vast majority of them have not thrived. Quite a few have been sitting idle in permanent alpha stage since I graduated high school.<p>When it comes to claims about Lisp's superior expressive power (as claimed here for example: http://www.paulgraham.com/power.html), quantitative data are also lacking. The only hard metrics on the subject that I can find are from the Computer Language Benchmarks Game. Incidentally, these measure the length of code in gzip bytes, which seems like a more fundamental consideration than LOC.<p>How do they compare Lisp to comparable languages in this regard? Not favorably. Here I'm using SBCL, as the default referent of Lisp is usually Common Lisp, but you'll find broadly similar results with other Lisp implementations, like Racket.<p>SBCL vs Python 3:<p>http://shootout.alioth.debian.org/u32/benchmark.php?test=all&#38;lang=sbcl&#38;lang2=python3<p>SBCL vs Ruby:<p>http://shootout.alioth.debian.org/u32/benchmark.php?test=all&#38;lang=sbcl&#38;lang2=yarv<p>SBCL vs OCaml:<p>http://shootout.alioth.debian.org/u32/benchmark.php?test=all&#38;lang=sbcl&#38;lang2=ocaml<p>And, indeed, SBCL vs Java:<p>http://shootout.alioth.debian.org/u32/benchmark.php?test=all&#38;lang=sbcl&#38;lang2=java<p>Here, Lisp appears to be a teensy bit more verbose on average than Java, which brought unto the world such marvels as the anonymous inner class.<p>Are there any more objective (as opposed to anecdotal) measures for the superior efficacy of Lisp?
======
tree_of_item
It's about the culture that the language enables.

Homoiconicity proposes a very particular philosophy of computation: programs
that read and write programs, something you wouldn't really even think of
doing in a language like Ruby. "Code is data" is not a meaningless mantra.

Emacs and Slime propose a very particular philosophy of programming:
interactive development in a live, dynamic environment. Growing and healing
programs rather than performing autopsies with the compile-edit-run cycle.

Counting packages on common-lisp.net and measuring program size in bytes
completely misses these points. This is why the zen mystique exists: Lisp and
its memeplex are not about quantitative things like "I can write program X in
Y lines", but about the way you think about computation and programming.

Not many languages even come close to the idea of proposing a robust and
interesting philosophy. Ask yourself what Java and Eclipse have to say about
the nature of computation.

Haskell is probably the other big one, and it'll be interesting to see how
that community continues to develop.

------
dsrguru
As I understand it, the main way LISP gives you a quantitative productivity
gain (evident from LOC or bytes or tokens) over other high level langauges is
that it lets you use syntactic abstraction (macros) to create highly
expressive DSLs that you use to write the main part of your application (e.g.
Viaweb or ITA). Otherwise, it might be fun to use, but it's probably going to
be less expressive than the likes of Ruby/Python/Scala, and maybe even than
Java, as seen by the benchmarks you provide. Nevertheless, people who know
CLOS and MOP well often claim that well-written LISP libraries are more easily
and concisely extensible than those of any other language. I don't have enough
experience to know if this is true. Even if it is, something in me says that
the time it takes to write those libraries probably more than makes up for the
time saved by using CLOS and MOP unless you have a very large team, but again
I don't have enough experience to know what I'm talking about here.

The other main advantage of LISP is that it facilitates what Paul Graham calls
"exploratory programming." Since most projects have unforeseen requirements or
future feature requests, the fact that the LISP development cycle is more
dynamic than that of any other language (I assume no one disputes this, but I
could be wrong) allows you to write code (and test and debug it ridiculously
quickly) that will be ultimately useful even before you know exactly where
your program is going. This mentality is basically the polar opposite of
Haskell, but both philosophies seem to work pretty well. :)

