
The Lisp Curse - llambda
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
======
irahul
Will it be too much to ask that the lispers build cool shit, and then brag
about how lips made it easy? That would be more pleasant compared to this
chest thumping.

The traits associated with lispers(lone wolves, nih syndrome, not interested
in boring tasks viz. documentation) aren't unique to lipsers. Most of the good
programmers, regardless of their language choice, suffer from this mentality,
and a lot of good stuff comes out of it.

CLOS is cool - I get it. And extending the language by parse time code
transformations is cool - I get that too. But does anyone seriously think
that's the only thing that makes cool shit possible? There is a lot of great
stuff out there which is written in languages which don't have macros, lot of
stuff which was written by lone wolves, lot of stuff which existed but was re-
written just because.

When someone is orgasming to perceived benefits of lisp(not all of it is
real), why does he have to make it look like "look lisp is so powerful, so
powerful it's harmful"? Can't you just leave it at lisp is powerful and it
helped me build this thing super fast. Why is this pathetic excuse of "it's so
powerful it's harmful" necessary?

And before you take out your pitch forks, please, you aren't the only one who
programs lisp. I like Clojure, but mostly because of its nice seq
abstractions, small core, interesting concurrency primitives, jvm. Macros are
very low in my list of reasons to like Clojure. I tried liking Racket, and
though I still like it, I would have preferred a higher level seq abstraction.
I have skimmed through "Practical Common Lisp" and I fail to see the charm -
there isn't anything which can't be conveniently and concisely coded in Ruby
or Python. Lisp has its benefits, but they are overblown.

~~~
evincarofautumn
I’d tend to agree. The powerful metaprogramming features of Lisp are often
unnecessary in day-to-day code, and definitely overhyped. It’s poor form to
use a macro when something simpler will do. They’re just another tool, and
when you need them it’s great to have them, but do all projects demand _the_
most powerful language features? Hardly.

However, I’m also with the author in that there are obvious social issues
arising from the existence of many implementations. If I write in C (or even
C++) using standard libraries, then I can be reasonably assured that my code
will compile anywhere. For obvious reasons, that’s not the case with Lisp
dialects despite their superficial similarities, but I think that catches many
neophytes off guard.

So even if such detrimental personality traits aren’t peculiar to Lispers,
there is a strong apparent correlation because of the “fractured” community.
Still, I think that has less to do with the power of the language and more to
do with its simplicity and lack of BDFL. Anybody can make their own Lisp,
their own object system, and no one will object—no pun intended.

~~~
irahul
> However, I’m also with the author in that there are obvious social issues
> arising from the existence of many implementations.

There are issues with competing implementations, but I would say that's not
totally bad(options are good) and over time, some equals become more equals
than others. Python has numerous web frameworks, attributed to the fact that
it's easy to define your own, but a newbie is more likely going to stick with
Django.

As I said, people re-implementing things "just because" isn't unique to lisp
and might not be as bad. Look at Flask - it was an April Fool's joke by Armin
which is now a proper micro framework. It isn't like Django wasn't the
dominant and recommended framework when Flask came into being. It's good to
have options and progress depends on people fooling around.

Look at async scene. You have twisted and you have gevent and you have diesel.
Templates? Jinja2, Mako, Django, Cheetah etc.

Python or Lisp, most of the people are going to make their choices and stick
with it. It's not like everyone who programs lisp starts writing their own
CLOS, and not everyone who programs Python tries to write his own framework
regardless of how easy it is.

> For obvious reasons, that’s not the case with Lisp dialects despite their
> superficial similarities, but I think that catches many neophytes off guard.

I don't know. Doesn't most of the programmers program to a particular scheme
or lisp implementation(sbcl, racket, clozure, gambit, clojure)?

> So even if such detrimental personality traits aren’t peculiar to Lispers,
> there is a strong apparent correlation because of the “fractured” community.

I think more than the "fractured" community, it depends on the out of the box
experience. If I am programming Racket, I won't try to build an object system
of my own - the one it provides is good. If I am programming Clojure, though
it doesn't provide a conventional object system, I agree with the choices and
won't try to implement my own.

~~~
jwhite
> > For obvious reasons, that’s not the case with Lisp dialects despite their
> superficial similarities, but I think that catches many neophytes off guard.

> I don't know. Doesn't most of the programmers program to a particular scheme
> or lisp implementation(sbcl, racket, clozure, gambit, clojure)?

Common Lisp libraries seem to be getting much more portable across
implementations, so within the CL dialect the language implementation is
becoming less of an issue I think. And QuickLisp is one counter point to the
OP -- it has broad community support.

------
stephencanon
I have a genuine fondness for lisp, but this article lost my interest pretty
quickly with the thought experiment. "Adding object orientation to C" doesn't
require "the programming chops of Bjarne Stroustrup"; you can write object-
oriented code in unmodified C (indeed, there are people who do exactly that).
Nor is C++ the only way to extend the language to add convenience to doing so.
Objective-C, for example, takes a completely different and much simpler
approach. C++ doesn't even satisfy the stated requirement of "keeping them
backward-compatible with the original languages, modulo some edge cases",
unless "some edge cases" means "large parts of the language" (semantics of
storage class specifiers and type qualifiers, what is and isn't an lvalue,
rules for implicit type conversion, ...)

From a certain perspective, these are silly little details, but if you don't
understand the silly little details of the other languages you write about,
why should I listen to what you have to say about the virtues of lisp?

~~~
bgilroy26
On he other hand, I didn't really need the C/objects piece of technical
evidence to support the "Lisp makes metaprogramming trivial in ways that other
languages don't" argument. That one kind of stands on it's own, so I could
move on to the rest of the article.

The article wasn't about Lisp as much as it was about Not Invented Here
syndrome. As others have said, the social and organizational issues become the
major obstacle when your working with the greybeards and technical wizards
that make the actual CS + CE questions a breeze

------
brownbat
I really wish people would stop citing the Paradox of Choice. The studies are
not reproducible, and meta-analysis reveals extra choices have basically zero
impact on consumers. We've apparently somehow learned to cope, which is
probably why a chain of supermarkets specializing in choice-free shopping has
yet to take off.

See Scheibehenne, B., Greifeneder, R. & Todd, P. M. (2010). Can There Ever be
Too Many Options? A Meta-Analytic Review of Choice Overload. Journal of
Consumer Research, 37, 409-425.

You can download it here:
[http://www.scheibehenne.de/ScheibehenneGreifenederTodd2010.p...](http://www.scheibehenne.de/ScheibehenneGreifenederTodd2010.pdf)

~~~
jeffdavis
> I really wish people would stop citing the Paradox of Choice.

Even if it were true, it's not as though there is no choice in other language
communities.

What python web framework should I use? I can choose among several well-
documented, supported, maintained systems; and if I need an extra library for
a specialized task, there's a packaging system to install it (and it's
probably well-maintained and documented, as well).

The times I've looked at lisp I just don't see that at all. Look here:

[http://stackoverflow.com/questions/540953/best-web-
framework...](http://stackoverflow.com/questions/540953/best-web-framework-in-
common-lisp)

Those frameworks are all either dead or pre-production-quality.

I'd like to like lisp, but I find that I'm a software engineer before a
computer scientist. Things like a good extension mechanism, good
documentation, a complete standard library, and a robust community matter more
to me than a powerful macro system.

Clojure and racket may be exceptions. I'll probably try one of those out.

------
ggchappell
I find this very interesting. Really, there is a larger principle here: that
in today's world, languages become popular, in part, by encouraging social
connectedness, e.g., forums for solving problems, interoperability between
different codebases, etc. The author's point, then, is that, perversely, one
way to encourage social connectedness, is to be almost-but-not-quite powerful
enough that one person can do everything alone.

I find a couple of misconceptions, though. The most glaring is the lack of
distinction between conceiving an idea, and implementing it. This is best
exemplified by the following:

> In a world where teams of talented academics were needed to write Haskell,
> one man, Dr. Tarver wrote Qi all by his lonesome.

Teams of talented academics, building on the work of others going back
decades, were required to _design_ Haskell. Once that design was done, anyone
could copy it. Sure, Tarver implemented Qi all by himself, and the fact that
he could is significant. But let's not talk as if Qi is based entirely on
ideas that he made up himself without considering the work of others.

~~~
bgilroy26
> In a world where teams of talented academics were needed to write Haskell,
> one man, Dr. Tarver wrote Qi all by his lonesome.

I think you're right about how the author is making an invalid comparison, but
I think his point still stands.

In order to make a good comparison, he would say the same things about Tarver
and Qi, but he would have to say something along the lines of "Lisp has been
extended in functional Haskell-y directions (Qi) and in object-y Smalltalk
directions (CLOS). It would be very difficult to extend Haskell in as many
dimensions as easily as it is to extend Lisp"

Not that you necessarily want functional languages to have Smalltalk flavors,
but I think it was wrong to compare Tarver with the academics like you say.
The plus for Lisp is that it makes implementation of language features easier,
you still have to come up with them just like everybody else.

------
stcredzero
_Lisp is so powerful that problems which are technical issues in other
programming languages are social issues in Lisp._

Here's my take on it: Social issues will swamp the technical power of any
language.

Corollary: Virtuous cycles in the social dimension will augment the technical
power of any language by an order of magnitude.

The over-arching principle: A programming language community is as much a
social artifact as it is a technical one. You have to get both sides right to
succeed.

~~~
mcguire
"Corollary: Virtuous cycles in the social dimension will augment the technical
power of any language by an order of magnitude."

To wit: Java, Go, C++,....

~~~
bane
It's interesting to note that most of the Java language design was
specifically targeted at the social aspect of writing software.

~~~
lubutu
But only that of certain social circles. For example, it fails miserably
(imho) as a "hacker's language". I suspect the social and technical aspects of
a language are inextricably linked.

------
lispm
TL,DR: repeats old misconceptions.

Task: go to the Apple Macintosh App Store. Download Clozure CL. Get Quicklisp.
Get libraries. Start hacking. Connect via #lisp, reddit/lisp, the CLozure CL
mailing list. Put your stuff on Github, make it available via Quicklisp.

<http://ccl.clozure.com/> <http://www.quicklisp.org/>

Have fun.

~~~
rprospero
Just took a look at QuickLisp and that's a big improvement over the last time
I looked at Common Lisp. On the other hand, there's a couple of points to
make.

1) While quick lisp does have an amazing array of packages, there's still some
simple, yet glaring deficiencies. For instance, there's no package to talk
over a serial port. If I go to Google, the top link is a stack overflow post
with some code on how to do that on Windows. The next few posts links are
either people being told to use the FFI or raw writing to /dev/stty with the
unix command line being used to set the tty parameters.

Comparatively, the first link Google returns for python is for PySerial, which
will handle all the serial port settings on its own.

I was originally going to use this as an example of contrasting documentation,
since I assumed that both languages would at least have a serial library.

2) If I want to send an e-mail, quicklisp offers cl-smtp and smtp4cl, while
python mostly just offers smtplib. On the other hand, the documentation for
smtplib (<http://docs.python.org/library/smtplib.html>) is readily available,
while cl-smtp is limited to the (admittedly clear) README file.

\---

I happen to love the lisp aesthetic (though I'll admit to preferring scheme
over CL). Still, the main thrust of the article is that Lisp is cursed with a
disorganized array of unsupported, poorly documented, incomplete solutions.
QuickLisp has only solved the disorganized part of that. If there's a bug in
smtplib, I can feel pretty secure that it will get fixed. Honestly, I bet I'd
have the same luck with cl-smtp, but what about smtp4cl?

I don't believe that it's a curse and I do think that it can be solved.
However, this is a cultural problem in the lisp community and ignoring it. To
put it differently, if we'd had this discussion four years ago, someone would
have brought up asdf and said that that solved all the problems. However, we
now have QuickLisp because asdf wasn't solving all the problems. It's great
and things are better than they were, but we're not done yet.

~~~
lispm
ASDF and Quicklisp are two different things. Quicklisp uses ASDF.

ASDF hasn't solved many problems. It was basically another system definition
tool (with a different license). We had them before. What ASDF provided was
that open source / free software used a common system definition.

Quicklisp OTOH provides a service. It uses ASDF. I provides library management
and a collection of libraries.

The process over that to improve these libraries, make them better documented
/ more portable / rated / ... is something that happens over time.

Quicklisp does not solve all problems. It does not aim to. But it solves some.

~~~
rprospero
I agree with you completely. QuickLisp does a damn fine job of solving some
major problems. Honestly, looking through QuickLisp while writing up my post
has made me consider moving from scheme back to CL for the first time in a
long time.

My comment about asdf mostly comes from my experiences back in 2005 when I
repeatedly heard that Common Lisp had NO problems and that asdf was so
superior to CPAN or rubygems that there was no need to implement a new package
system. In the same way, I often heard that we didn't have an issue with
insufficient libraries, since UFFI (or was it CFFI?) has solved all of that. I
wouldn't have been surprised if those same commentators would today declare
that QuickLisp has solved everything.

However, those conversation that I had back in 2005 were not with you and I
apologize for putting words in your mouth.

------
praptak
Clojure so far looks like a Lisp designed with at least some awareness of this
curse. It has a strong "one obvious way to do it" flavour to me and I hope the
devs will keep it this way.

~~~
gtani

        Every second or third serious Lisp hacker will roll his   
        own implementation of lazy evaluation, functional purity, arrows, 
        pattern matching, type inferencing, and the rest.
    

Seems to describe clojure pretty well, tho I don't know about arrows, i
haven't gotten that far into categ theory vs. real world implementations

~~~
asmala
I tend to disagree. Unified solutions exist on the level of the core language
and libs for both lazy evaluation and (pragmatic) functional purity, and the
recent discussion around logic programming and pattern dispatch implementation
is a beautiful example of how some really smart people are working together
towards a common solution, instead of everyone rolling their own.

------
Tycho
I find Lisp a bit unsettling because when you look at the code it's like
you're looking at pure abstraction... there is a lack of semantic/symbolic
content to latch on to and feel 'anchored.' Gives you the feeling that if you
use Lisp, you'll have to be thinking _hard_ the whole time you're using it.

~~~
gruseom
I'd be careful about drawing any conclusions from a first, second, or even
tenth impression. That unsettling feeling may just be unfamiliarity. What you
really want is a sense of what it would be like after you've developed a feel
for it - admittedly something of a chicken-and-egg problem.

What used to feel like "pure abstraction" to me now feels like lightweight (if
dense) code whose shape is determined by the problem rather than by arbitrary
constraints and noise.

~~~
Jach
The standard image macro meme for newcomers to Lisp is this:
<http://img264.imageshack.us/img264/1397/lispnd7.png> But I agree there's
something more as you work with the language and start mastering macros,
perhaps it's similar to the Tetris Effect, and the process takes you from
frightful screams to delusions of grandeur back to solid practicality and
programs that solve a problem. The process may take a while.

------
jamesaguilar
I tried to write a Lisp application once. Couldn't figure out how to make
something standalone that could be run from bash. Most of the websites and
discussions I looked at around the issue suggested that one would be wrong for
even wanting such a thing. Eventually did my project in python.

~~~
lispm
You could have read a manual (creating standalone applications is documented
for each implementation) or asked other users.

SBCL:

<http://www.sbcl.org/manual/#Generating-Executables>

CLISP

<http://www.clisp.org/impnotes.html#image>

and so on...

~~~
mcguire
SBCL: "This implementation is not as polished and painless as you might like:

"It corrupts the current Lisp image enough that the current process needs to
be killed afterwards. This can be worked around by forking another process
that saves the core.

"There is absolutely no binary compatibility of core images between different
runtime support programs. Even runtimes built from the same sources at
different times are treated as incompatible for this purpose.

"This isn't because we like it this way, but just because there don't seem to
be good quick fixes for either limitation and no one has been sufficiently
motivated to do lengthy fixes."

CLISP: "Memory images are not portable across different platforms (in contrast
with platform-independent #P".fas" files). They are not even portable across
linking sets: image saved using the full linking set cannot be used with the
base runtime:

    
    
        $ clisp -K full -x '(EXT:SAVEINITMEM)'
        $ clisp -K base -M lispinit.mem

base/lisp.run: initialization file `lispinit.mem' was not created by this
version of CLISP runtime"

These are the sorts of perennial problems common to image-based languages,
specifically those that use "undump"-ish methods to create executables.

~~~
lispm
That dumping an image lets one quit the image dumped, that images are bound to
certain versions of the runtime, etc. are inconvenient for users of images. It
is a non-issue for creating an executable.

------
wpietri
The linked article "The Bipolar Lisp Programmer" is brilliant:
<http://www.lambdassociates.org/blog/bipolar.htm>

I don't know how correct it is about Lisp in specific, but he's definitely
nailed a familiar type.

~~~
lispm
Mr. Tarver failed to see that this is not specific to Lisp.

------
wedesoft
> Lisp is so powerful that problems which are technical issues in other
> programming languages are social issues in Lisp.

I think this is a rather stupid argument. The same way you could argue that a
boat is a better means of transportation than an airplane. With the boat
agreeing on a holiday destination is less of a social issue because it is
limited by technical constraints anyway.

------
siavosh
I wonder though if this is an out of date concern because the last time Lisp
was popular was before the proliferation of open source and tools like github.
As a newbie Clojure programmer, I feel like I've already come across some very
successful open source frameworks/libs (ex. Noir, Storm).

I do get concerned though how PL fads seem to move in circles, and would love
to learn more why Lisp is experiencing a renaissance. What's changed?

~~~
lispm
Lisp had open source before you had it. The Lisp implementations were already
shared during the 60s. They travelled by tape. The github of that time was the
time-sharing system, where hundreds of users shared a computer and its
storage: mainframes and large minicomputers.

See ITS:

<http://en.wikipedia.org/wiki/Incompatible_Timesharing_System>

The MIT in the 70s and 80s had LANs and file servers already. The networked
Lisp Machines used common repositories. There weren't passwords. Different
sites shared files via tapes and via the early ARPA net. Losing this when the
MIT commercialized some of the technology inspired Richard Stallman to start
the free software movement.

Lisp and AI users collected and shared a lot of software. See for example this
repository with software from the 80s and early 90s:

<http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/0.html>

Sharing was done via FTP servers.

When Common Lisp was initially developed from 82-84, immediately open source
implementations (with different licenses) were created: CMUCL, KCL, AKCL, WCL,
CLISP, ... which can be traced to today's SBCL, ECL, CCL, ABCL and others.

------
ChristianMarks
Managers want employees to be fungible, so they hamper their employees. That
points to a severe Principal-Agent problem. Why not ban programming altogether
and make them parrot the venerable ITIL corpus?

The post is stunningly ignorant. Alan Kay points out that actual programming
practice represents a tiny fraction of what is known. The answer isn't for
managers to create Principal-Agent problems by dumbing down their employees,
but hiring knowledgeable managers who recognize the abyss that separates the
state-of-the art from industrial practice. Startups emerge from this gap in
understanding.

------
Xion
_Consider the case of Scheme, again. Since making Scheme object-oriented is so
easy, many Scheme hackers have done so. More to the point, many individual
Scheme hackers have done so. In the 1990s, this led to a veritable warehouse
inventory list of object-oriented packages for the language._

It's funny that something quite similar can be said about today's arguably
most popular and ubiquitous language: JavaScript. Each of MooTools, ExtJS,
Prototype etc. sport their own model of OOP, with minor or even major
differences. Yet it doesn't seem to be so big of an issue that it prevents
cool stuff from being done in JS. For one, I don't think many people would
claim that you _need_ some implementation of OOP (i.e. classes, inheritance 'n
stuff) to effectively program in JS. The readily available mechanisms are
perfectly sufficient to just start coding what you want to code and doesn't
require "amending" the language first.

JavaScript code generally seem to be fine with that and happily proceed to
create another batch of coolstuff.js. But according to the article, Lisp
hackers have totally different mindset: they first "create a language" and
only then proceed to use it to actually code stuff. (There is quote about
giving man a Lisp...) If that's indeed true, I don't think it's really an
issue of the Lisp itself, i.e. it's all-too-great power. After all you can
just proceed into writing your _program_ rather than writing a _language_
first - like in JS. If Lisp coders fails to do that, I would say it's a
problem of Lisp coders.

------
akkartik
Previous discussion from a year ago:
<http://news.ycombinator.com/item?id=2450973>

~~~
winestock
I'm surprised. I wrote this essay a year ago and it's _still_ getting
attention. I've received occasional upvotes for that post since I submitted it
but I have no idea why it made it to the front page again.

------
whackberry
This is bullshit. People adopt languages because interesting things are made
in them. The most interest I've found in lisp has been Emacs, because it's an
awesome editor. If more Emacs-level projects in lisp were out there I bet lisp
would be more popular. Otherwise, this is just political bravado with no
concrete aplication.

~~~
lispm
'interesting' is a somewhat vague concept. You need either 'interesting for a
lot of people' and/or 'easy enough for an implementor who would create such a
thing'. It is also important that a programming language and its
implementation is used by people who develop new stuff. Currently no large
company supports Lisp for that - not Apple (they did that in the 80s), not
Google, not SAP, not ... Sometimes they buy technology which has traces of
Lisp. Google bought ITA software - they are a Lisp shop. Apple bought Siri,
Siri had traces of Lisp in - the original research project was done at SRI,
which assembled modules written in many languages - among them Lisp. But
that's it.

When display-oriented text editors were developed, very early Lisp programmers
implemented them in Lisp and even created engines which were portable for it
(the Emacs C part which implements a simple Lisp runtime).

When a CAD company needed an extension language, they added a simple Lisp
dialect written in C to their CAD system. Born was Autolisp for AutoCAD - used
in millions of installations.

Today there are enough alternative languages around which can be easily
embedded - for example Lua.

Common Lisp is slightly more difficult to embed. One either uses ECL
(Embeddable Common Lisp) or a home-grown Common Lisp variant. Which for
example Quicksilver ( <http://www.broadvision.com/en/quicksilver.php> ) or
PTC's CREO Elements ( <http://www.ptc.com/product/creo-elements-direct> ) do.

You might never hear of the latter two - they are interesting applications -
but not used by that many people.

There are interesting and unique applications written in Common Lisp - but
their user domain is very specialized. In music composition you could use
OpenMusic, PWGL and several others. In cognitive modelling (used for example
to test user interfaces) ACT-R is used. In proving correctness of software
something like ACL2 or PVS might be used.

But these are certainly not the interesting applications you have in mind,
even though there were probably hundreds of interesting research projects done
with something like ACT-R - but it is software for a narrow user group.

------
gouranga
Ok to be honest I agree, but in a different way. The curse is when you have to
go back from a Lisp variant to a crappy procedural language. It just makes you
cry, even if it is really more productive than Lisp.

