
Lisp's reputation is so bad that many people don't even take a look at Lisp - iamelgringo
http://ilc2009.scheming.org/node/6
======
pc
This reads like a Chinese government strategy document: "the world thinks we
suck. How do we convince everyone we're vibrant and fun-loving?"

I've been a Lisp hacker for years -- Symbolics Lisp Machine in my bedroom,
coded in at least a half dozen different Lisp dialects -- but I ended up using
Smalltalk for my startup. Treating Lisp's "rehabilitation" as a mere branding
exercise shows just how screwed the Lisp community still is, and is
symptomatic of the underlying issue. (By "Lisp", I mostly refer to Common
Lisp.)

Lisp's problem is a meta-problem. The community is actively _resistant_ to
advancement, change, and evolution in the language. Attempts to modify (or
even clarify) aspects of the Common Lisp standard are tedious exercises in
futility, but the standardisation straitjacket is still seen as a good thing.
A bit strangely, this resistance to change existing standards is accompanied
by a slowness to standardise (even informally) anything that isn't already.
The end result is that there's still no reliably portable way to write
networking code in CL.

And this is why Lisp is unpopular.

The stasis is sad and ironic, given Lisp's hackerdom beginnings. Rather than
wonder why, in 2009, so few are using Lisp, we should be amazed that the
language is still pretty cool two decades after the innovation stopped.

I hope the Clojure guys change things. They seem to have the right approach.

Footnote: I was going to be a member of the CLRFI group (roughly equivalent to
PEP or SRFI) that got some interest at ILC 2005, and which was going to try to
create some sort of forward momentum in the community. It frizzled out, of
course, and now <http://clrfi.alu.org/> appears to redirect to the ALU
homepage.

~~~
jimbokun
"I hope the Clojure guys change things."

In many ways, Clojure seems like a deliberate response to each of the common
complaints against Lisp.

    
    
        Lisp is old and moldy. It must be primitive by today's standards.
    

Hard to call Clojure "old" when it's only been around a couple years.

    
    
        The exciting languages to learn now are Python, Ruby, Groovy, etc.
    

Clojure has been very successful at building nerd "street cred." It has
latched onto the fascination with functional programming for parallel
applications, for one. It also makes use of concise syntax for data structure
literals, like Python and Ruby, too. Dynamic, etc. etc.

    
    
        Lisp is only for artificial intelligence.
    

Don't think Clojure has this problem.

    
    
        Lisp is interpreted and slow.
        Lisp programs page heavily, so they're even slower.
    

Clojure gets the performance benefits of running on the highly tuned JVM, with
tricks like type hints to get close to Java speeds for critical portions of
code. Worst case, you can always drop into Java as your "assembly" language.

    
    
        The parentheses look weird and hard to manage.
    

Clojure mixes up () with [] {} to make code easier to mentally parse.

    
    
        Lisp uses prefix notation for things that every other popular language
        does with infix notation, which is just very weird. (And it leads to
        more parentheses.)
    

No change here.

    
    
        Lisp is too big.
        Lisp is too hard to learn.
    

Clojure is pretty small and doesn't take much time to get started.

    
    
        Lisp is all about lists and recursion; that's all you do with it.
    

Some might start to think "Clojure is all about functional programming." Don't
know if that's good or bad.

    
    
        I don't know which implementation to use.
    

There's only one Clojure implementation.

    
    
        It isn't "batteries included" (that is, it's not easy to get set up with all the tools and libraries you need).
    

You get all the libraries written for Java.

    
    
        I don't like Emacs, and you can't use Lisp without Emacs.
    

I use Emacs, which is also great for Clojure, so I can't judge how easy it is
to program in Clojure without Emacs.

    
    
        Lisp isn't useful for my career; few potential employers want it.
    

You might be able to sneak Clojure into a Java shop.

~~~
sross
No offense but I don't think you get the concept of batteries included. Python
has batteries included, Clojure has batteries available.

Even the clojure contrib jar is not included by default and has to be
downloaded separately and then clojure needs to be launched with extra command
line arguments to setup the classpath properly (or you need to fiddle with the
classpath from within clojure), the same goes for any Java library that you
want to use.

~~~
jimbokun
Except for the classes in the JDK. That gives you networking, file I/O, string
processing, regex, Swing GUIs, JDBC, ZIP compression, some XML processing,
among other things.

Even by itself, that is better than most Lisps out there, if not enough to
make a Pythonista happy. The problem with this stuff is usually the painful
verbosity of Java necessary to use it, but you can wrap away that pain very
quickly with Clojure.

I do take the point about needing to fiddle with the classpath for any other
Java code you want to use. But for me the Java classpath system holds up
better than most other software deployment mechanisms. Usually, you just
download a jar file, drop it on your classpath, and it just works. I think jar
files are an unappreciated success story of the Java ecosystem. Clojure has
functions to easily add jars to the classpath at runtime, which is even
better, but I find it does not always work seamlessly for me.

------
lsb
I went to see if there was anything like ActiveRecord for Lisp, because, well,
that's a pretty metaprogramming-heavy domain. What do I get as the first
google hit? A forum post asking about that,
[http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2006...](http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2006-04/msg00735.html)
\--- never a good sign. Two people answered, one with a link to his rant on
comp.lang.lisp, and one talking about the virtues of CLSQL.

The code snippet from CLSQL looks horrendous:

    
    
      ;; select the user with ID 1 and set his username column to joe
      (let ((user (first (select 'user :where [= [id] 1] :flatp t :refresh t))))
        (setf (username user) "joe")
        (update-records-from-instance user))
    

Compare this to

    
    
      User.find(1).update_attribute(:username, "joe")
    

16 tokens vs 45. I don't know CLOS, but

    
    
      (update-attribute (find *User* 1) 'username "joe")
    

is a great start.

~~~
antiismist
I've been using leftparen (a framework written in PLT Scheme) for a project,
this would be something like:

    
    
      (rec-set-prop! userid 'username "joe")
      (store-rec! userid)

------
sbt
I've been programming in Common Lisp for about a year and I consider myself an
intermediate beginner. Someone made a terrific comment in response to Ron
Garret's post earlier: the way you get productive in today's environment is
primarily through libraries.

Thus the situation is inescapable. You need tons of libraries to be
productive. You need tons of programmers to write these libraries. You need an
easy learning curve and appealing features to get these programmers. The
bottom line is that you need the bad coders as well.

As a beginner, I can safely say that it took a while before I finally got
reasonably productive in Lisp. I still consider it 'the best' programming
language. But the learning curve is much steeper than Python.

Lisp will get nowhere without all the bad programmers. This may sound cynical,
but the reason is that academically minded programmers won't spend time
writing things like a download library for youtube videos, which many people
find useful. These programmers are now all over Python.

So why is Lisp difficult to learn? The most severe in my opinion is
assignment. People find it intuitive to make temporary variables and store
intermediate results in these. This is done by 'let' in CL, but if the
previous style of programming is assumed, 'let' is clumsy and inconvenient to
use.

Another achilles heal I would like to mention is the lack of an editor with
propper auto-completion. Yes, slime does this, but using emacs is too geeky
for many programmers (remember you need these people) and this creates an
additional stumbling block.

Yet another problem is the CL websites. Remember that many people are in a
hurry. The Python website is ripe with snippets that lets you do stuff fast
without understanding much. In contrst, CL gives you some of the most monotone
autogenerated documentation sites I've ever seen. Again, fine for people who
already know Lisp, tedious for people that want to try stuff out as beginners.

Faced with these realities I don't blame anyone who just want to get things
done and run with Python. Unfortunately.

~~~
jrockway
_Someone made a terrific comment in response to Ron Garret's post earlier: the
way you get productive in today's environment is primarily through libraries._

I think that was me. FWIW, I find CL's libraries to be adequate in many cases,
but certainly not as good as Perl's.

(I have done a few Java projects, and I don't consider their libraries
adequate at all. You are either stuck with full-stack frameworks, or a legacy
API from 1995. I've also found that most Java programmers that write libraries
don't know what OO is, and that makes the libraries painful to use. YMMV.

Slime is also vastly easier to use than Eclipse, even with "emacs emulation"
turned on. Again, YMMV. :)

~~~
10ren
I don't know the specific Lisp or libraries involved, but reddit (YC funded)
famously switched from Lisp to Python, (mainly) due to libraries.

<http://blog.reddit.com/2005/12/on-lisp.html>

------
tetha
I belong to those people who tried to get into lisp and gave up, because the
confusion to navigate per potential advantage over my major language (python)
was too large. My background is a knowledge in C, Python and Java, using
Python mostly. I mostly looked into lisp, because I kept encountering
something I call the syntactic barrier when I tried to remove duplication from
my code, and I knew: lisp had macros. Macros could break this barrier. So
looking into lisp looked promising.

I didn't care too much about the syntax, a good editor fixes this without a
problem and it was a good opportunity to look into emacs a bit (usually, I use
vim). Surfing through the chapters of practical common lisp when pretty well
and understanding was not exactly hard.

However after that, I was faced with confusion. There is a boatload of lisp
dialects, each with a boatload of implementations and each implementation as
another boatload of libraries that do something looking similar to what other
implementations libraries do without being the same or compatible. How am I
supposed to select any of these without having a clue? After a few days of
back and forth, I decided to close the book lisp for me, because I could not
find a way through this wall of selections -- at least not without investing a
lot of time. Too much time for too little benefit over python.

HTH, Tetha

~~~
10ren
Some people (like esr) say the main benefit of lisp is not to use it, but to
use the insights it gives into how to think about code. It may be that you
already have that.

~~~
silentbicycle
I agree, but if a language _doesn't_ teach you things you can use outside of
it, that's a really bad sign. This is in no way unique to Lisp.

(I've been meaning to write about things I've learned from the dozen or so
languages I've at least dabbled in, but haven't had the time.)

------
catch23
Hopefully some of the cooler Lisp dialects like Clojure & Nu will help out a
bit. The "crazy parentheses" is usually the core reason people hate lisp, but
until they realize its power, it's stupid stuff that prevents them from
learning it.

For example, Nu is one of the coolest languages out there that allows one to
do quick and dirty "scripting language" hacks in Objective-C. Due to Lisp's
simple structure, Nu was able to directly map Objective-C method call
signatures into something that clearly looks like basic Lisp. It allows one to
code in 2 languages, but the Objective-C part of the language actually looks
very similar to normal ObjC. One of the biggest benefits of Nu is that writing
unit tests in ObjC is no longer painful... the whole testing structure is as
simple as typical ruby unit test cases.

Clojure is another one of those wonderful libraries that is a must-have for
anyone doing normal java. Even basic string manipulation is extremely verbose
and annoying in Java, but is probably too heavy to load a JRuby/Jython
interpreter... I think that's where clojure helps fill the gap. I recently
implemented an "equivalent" of a google-analytics tracker in Clojure and the
final result was only around 200 lines of code (with a little bit of java here
and there). It's quite nice to use clojure as a glue-language to make all your
java libraries work together with little clutter as possible.

~~~
SwellJoe
_The "crazy parentheses" is usually the core reason people hate lisp_

I very strongly suspect that the "crazy parentheses" is not actually why most
people who hate Lisp hate Lisp. Crazy parentheses are nowhere near the top of
my list of reasons, anyway. And, blaming parentheses is the same as
complaining about the sigils in Perl or the significant white space in Python;
it's just not a very intelligent argument, and can probably safely be
dismissed as merely uninformed. Sure, you like what you're accustomed to, but
you can become accustomed to different syntax quite easily...one or two weeks
is all it took for me to switch from Perl to Python, and then back again a few
years later.

A syntactic difference is just a very simple concept to latch on to; both for
those who hate Lisp (for whatever reason) and those who want to explain away
the people who hate Lisp (without having to address the real, but complicated,
problems). There are a lot of very good reasons to hate Lisp, but they take
more than one or two sentences to explain, and most folks just aren't going to
invest that much effort in talking about something they just don't have that
much interest in.

The linked article does mention a few of the very good reasons to hate lisp,
and leaves out a couple that I think are possibly even more important:

\- Lisp has a community that is generally hostile to newbies and outsiders
(mentioning other languages, in particular, seems to be a big source of
trouble). Contrast this with just about _any_ other modern dynamic language
community. Friendliness is practically religion in the Perl, Python, and Ruby
communities (though I think only Perl has a formal religious institution for
the purpose at perlmonks.org ).

\- A community that has a deeply ingrained culture of NIH. There are dozens of
incompatible Lisps, with dozens of incompatible libraries for all sorts of
tasks. I've found Lisp to be the most difficult language with which to produce
useful software as a beginner of any dynamic language I've tried. Not because
Lisp is inferior to Perl, Python, Ruby, etc. but because I found it impossible
to find any combination of components that made it possible for me to produce
useful software without running into bugs or incompatibilities that my weak
knowledge couldn't overcome. Even if Lisp allows for code that's half or a
quarter the size of any other dynamic language (which seems an unlikely
compression), the sheer volume of excellent libraries in Perl/Python/Ruby
means I can write a tenth the code, making those languages a win even if the
total line count, including libraries, is higher. I've been told (grouchily,
in keeping with the smug Lisp weenie tradition) that _tons_ of great libraries
exist for Lisp. Despite this assertion, I've never been able to build even a
toy (but useful) project in Lisp.

~~~
berntb
Lisp was my favorite language when I studied (hrm, long ago).

IMHO, there is quite a lot of support for the argument that modern day
scripting languages are getting closer and closer to becoming lisps, except
for syntax and the macro system. (Maybe Perl 6 will have meta-language power
enough to equal the macro system? I should start learning it.)

I've never really understood why there are no successful projects to transfer
code between the S-EXPR parenthesis-based syntax and some Algol-like notation;
if that managed to also copy comments between the formats and auto formatted
well, it would be an easy introduction for new lispers.

~~~
SwellJoe
_Maybe Perl 6 will have meta-language power enough to equal the macro system?_

Not only does it have full-on raging macros, you can redefine the languages
own syntax inline. Check out one of Larry's recent talks about STD.pm (here's
a Google Tech Talk from last year, which is nowhere near as funny as Larry
usually is, but is still quite informative:
<http://www.youtube.com/watch?v=JzIWdJVP-wo> )for a real "when you see it,
you'll shit bricks" moment. Perl 6 is far more intimidating than I ever
realized. They seem to have looked at everything good about Perl (and a
handful of other languages) and said, "Let's do a lot more of that." It's
somewhat scary how much more of "that" they've done. So, there's macros from
Lisp, lazy evaluation from Haskell, redefine-able grammar and syntax from I
dunno where, a new regex language, etc. It takes TMTOWTDI to obscene new
heights (kinda like Lisp). If power is the sole determining factor in what
language you choose, there's a strong case to be made that Perl 6 is the one
you want. I don't know that I entirely buy that (if I did, I guess I'd be
using Lisp), but I'm hopeful that the real result of Perl 6 will be a language
as capable as Lisp with a community and library culture as strong as Perl 5.

~~~
berntb
What I meant was, will it be as easy to use as lisp macros?

To take most everything good existing and sum it, is how you make Perls. :-)
I'm not arguing here, I do Perl today.

You should have put the content of the last sentence first; too few will read
it.

------
patio11
_The problem is, someone with these preconceptions often doesn't even look for
our replies!_

How's about conceptualizing the problem less as "People don't come to the
light about how Lisp is not as problematic as they think it is" and more as
"We need to explain better how people's lives are going to improve if they
learn and use Lisp". (I know, I know, I may have just committed the sin of
marketing. Please forgive me.)

I do not have a Lisp-sized hole in my life right now.

~~~
silentbicycle
I think ensuring first that peoples' lives _would_ be helped if they learn and
use Lisp is important, too. Some people take this for granted (and can come
off as incredibly condescending, PS), but I'm not so sure anymore.

I know (and _really_ like) Scheme, but the balkanized Scheme ecosystem can be
very confusing to curious onlookers, and can make finding one implementation
with all the libraries relevant to a project difficult. There's the tiny core
language, then there's a bunch of SRFIs that implementations choose whether to
support, and implementations are all over the place as far as quality,
libraries, and portability. (I eventually settled on Chicken.)

I learned some Common Lisp, but ran into so many portability and library
problems, for stuff that would be trivial in Python, that I ultimately gave up
on it. In retrospect, Scheme is a much better fit for my taste, anyway.

For a while, Python was my default language for real work. (Lately, I've
switched to Lua. They're quite similar, though Lua has incorporated more of
Scheme's good ideas, has more of its own, and has a _much_ cleaner design,
IMHO.) While neither has macros, they have a collection of libraries, an
active community, an obvious standard implementation, great support for
interactive development, a decent syntax, etc. Macros aren't everything, and
SwellJoe's comment about NIH (<http://news.ycombinator.com/item?id=550634>) is
_absolutely_ correct. (Lua's design, in particular, assumes from the start
that it will be embedded in something else. It's very simple to use it with
other languages and their libraries.)

While I don't know Ruby (Python & Lua already fill that niche for me), I'd
expect Ruby programmers find similar productivity there.

~~~
anonymousDan
I wonder how much this balkanization is a result of the syntactic extension
capabilities of lispish languages? The fact that you can implement changes to
the language in the language makes it easier to improve it in terms of coming
up with new features/patterns etc. However this can be a double edged sword
when you need to then train large numbers of programmers in order to create
libraries etc. for the new language. Or maybe its not that the splintering
occurs directly because of the language. Instead it might occur indirectly due
to lisp programmers, having been exposed to the idea of language extension
through lisp, become more prone to creating a whole new language when the one
they have doesn't suit their needs precisely?

~~~
silentbicycle
Well, first, the core Scheme spec is _tiny_. Tons of people have written at
least half-complete Scheme interpreters (self included, in OCaml). It's a fun
project, and it teaches you a lot about programming, even if you don't do the
tricky parts (like full continuations). This seems to feed a strong "just fork
your own" sentiment in the community, though, and that probably leads directly
to a mishmash of incompatible libraries. That's Scheme, though, not Common
Lisp; CL was an attempt to reign in several divergent Lisp dialects.

Also, I think people overuse macros. Certain people have put a lot of time
into promoting them as the biggest asset of the language, which tends to
encourage people to use them where they're not only unnecessary, but likely to
make code harder to understand / maintain. (See, for instance,
<http://news.ycombinator.com/item?id=542746>. Especially: "Q: What do you get
when programmers design a language while trying to get something else done? A:
PHP")

While I'm not knowledgeable enough about Ruby to say for certain, I could see
making a big deal about "monkeypatching" causing similar problems there. Maybe
the Ruby community encourages more restraint, though. Anybody?

------
blue1
I absolutely love Common Lisp, but it has some problematic areas, which are
not the classical stupid ones you sometimes still hear from clueless people
(such as "lots of parentheses", "lisp is slow", "lisp is for AI only" etc.).

I won't even say that libraries are a real problem. Sure there is no CPAN, but
still there are a lot of very good CL libraries around, and they are not
really hard to install.

But:

1\. The language is sophisticated. This is a "problem", in the sense that such
a language takes time to study. It will never be popular. The Condition system
and CLOS, for example, are way more complex and versatile than, say, the
equivalent areas of Java. And then there are macros. Common Lisp has not been
designed as a mainstream language for mainstream programmers. It is, I fear,
an elite tool.

2\. Certain kind of operations are inconvenient. Maybe when CL was designed,
sockets, multithreading, text processing etc were not so popular. But now, it
feels like CL has not really adapted well to the modern world. Having to
install a compatibility library for using sockets is reminiscent of things
like "trumpet winsock". Does not feel very cutting edge.

3\. The literature is lacking. "Practical Common Lisp" is very good, but one
book is not enough. For example, what are the best practices to organize large
CL programs? No book tells it (maybe some obscure out-of-print text that I
have not yet tracked?). What about programming idioms, or patterns as you
prefer? Apart from an ancient presentation by peter norvig, nothing exist. And
so on.

4\. The ANSI standard is a big blessing and a big curse. It is a well-written
and smart opus. But nowadays no one has the resources for a new standard; both
in terms of money and focus. This means that ANSI CL seems an ancient pinnacle
of beauty which will never be equalled and certainly can not be improved. (the
perfection of ancient architecture, as seen by renaissance architects, comes
to mind). This makes CL a splendid but dying civilization.

5\. I have a feeling that the community is slowly dying as well. While in
recent years many CL sites and blogs have appeared, comp.lang.lisp has lost
many important contributors. Nor I can really blame them: while still a
wonderful language, CL is nonetheless petrified, and I suppose one may became
slightly bored after a decade or two of discussing the finer points of the
Standard.

~~~
sandGorgon
You're dead-on about the lack of literature. I am no lisp expert (python stole
me away), but something like the PythonChallenge for lisp could go a long way
towards building a working knowledge. I really wish we could have books like
Norvig's PAIP in the public domain - it is really one of the best books on
lisp ever, however very expensive - more so in third world countries. Oh and I
really wish that brackets were used rather than parantheses - there is RSI you
know!

~~~
silentbicycle
It seems particularly telling to me that Norvig himself seems to have switched
to Python for most work.

Christian Queinnec's _Lisp in Small Pieces_ is another absolutely brilliant
book on Lisp, btw. It and PAIP are both about equally expensive, but both are
well worth it IMHO. (FWIW, PAIP is probably of more interest to people with no
intention of using Lisp.)

(Also: Remapping your keyboard helps, whether you do it in your editor or
overall. And, I did not write the above just to say "IMHO FWIW PAIP". Honest.
:) )

------
jobeirne
In response to the parting question from the article, here's an idea: make
cool things with Lisp. Make cool things _for_ Lisp.

~~~
jcl
That seems to be how Erlang has achieved its recent popularity... some big
successes in telecommunications systems and ejabberd.

------
pavelludiq
Before i learned scheme(I don't know CL), i didn't know how to write python. I
knew how to write python syntax, but had no idea how to write code that
doesn't suck. I still write bad code, but at least i know when its bad and i
need to change it. Scheme thought me how to spot ugly code. I still use for
and while loops(recursion is expensive in python, and you shouldn't write
scheme in python) but i learned to write small and simple functions and
combine them in smart ways(list comprehensions, maps, filters, decorators...).
I guess i knew that from reading about the unix philosophy, but it took me to
see it in code to understand it. So learning scheme might help you to be a
better programmer, or it might screw you up and you end up writing stuff like
this <http://www.pick.ucam.org/~ptc24/yvfc.html>

p.s. I've never written anything longer than a textbook exercise in scheme, so
i don't know if you can actually write real stuff in this(or how hard it is)
but playing with it is really fun, you should to it just for that.

------
praptak
My suggestion for anyone wanting to make Lisp popular: make a Lisp analogue of
Mark Pilgrim's "Dive Into Python". Or at least consider whether it is possible
to write such a book for Lisp in its current state.

~~~
halo
Isn't that Peter Seibel's "Practical Common Lisp"?

~~~
sbt
Pretty much. PCL is a great book that did much to bring the O'Reilly flavor to
the community. Another good contribution is the Common Lisp Cookbook website,
that contains snippets for common tasks.

Sadly, this doesn't seem to have struck the heart of the problem (although
Lisp-in-a-box that came with PCL seems to have done it for some people).

Think about why Java is so widely used. I would argue that it's because of one
thing: portable packages.

------
jcromartie
Can someone explain the "it's only for AI" objection that people bring up? I
have heard it from a few people first-hand and they couldn't say much else
about it. Is it like "Macs are just good for graphics?"

~~~
silentbicycle
Some people (apparently) assume Ruby is only for the web; they're confusing it
and Rails.

Lisp was closely associated with AI a few decades ago.

