

The Lisp Curse - winestock
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
Come on, everyone!  Let's beat the dead horse one more time!
======
sedachv
The Lisp Curse is all the people writing opinionated articles about the Lisp
inferiority complex, instead of contributing to existing Lisp software.

There are tons of incompatible, undocumented libraries for Perl, Python and C.
This is no correlation to anything. The people who want to use existing
libraries use them. Those who want to reinvent the wheel will do that and
there is nothing you can do to stop them.

Lisp Machines aren't magic.

If you think GNU Emacs is "obsolete," you can work on <http://common-
lisp.net/project/climacs/> or <http://common-lisp.net/project/phemlock/> or
<http://mclide.in-progress.com/> , but don't expect anyone else to share your
opinion. GNU Emacs is the best multi-language, multi-platform programming
environment available today. Most people somehow manage to avoid the "Lisp
Curse" and just work on improving Emacs extensions.

~~~
agentultra
I wish I could up-vote you twice.

Even his remarks about object orientation are just a straw man. Perl5 still
doesn't have a definitive object model (well, beyond blessed hashes). Library
authors have written many competing solutions over the years. Arguably this is
a good thing. If someone finds a better way to do something, everyone can
benefit without waiting for the Perl core developers to implement it.

Contrast to Python where we have to wait for the core team to implement
everything including the core libraries.

I don't know why this idea of writing "Why Lisp Sucks" articles persists.
Maybe it makes the authors feel smart and authoritative. I honestly don't
know. Can someone fill me in please?

~~~
winestock
As I wrote in another comment, I wrote the essay because the idea had been
bouncing in my mind for some time and I needed to get it down. The disconnect
between Lisp's power and its lack of mind share is downright odd given what it
can do and how influential it has been.

I wouldn't be surprised if some old-timer on comp.lang.lisp were to relate a
heart-rending tale of an inner-city high-school dropout thalidomide baby who
was a pity hire at LMI in 1987 and _blah blah_ s-expression this and _blah
blah_ Lisp macros that and _blah blah_ his flippers could barely reach the
Hyper key and _blah blah_ he did things you people wouldn't believe but _blah
blah_ Worse is Better so _blah blah_... Okay, okay; I believe you.

Then I would read Lisp sites that were still debunking old myths like "Lisp is
an interpreted language and its only data structure is lists and it caused the
AI Winter."

After a while, people are going to wonder about the disconnect. There's a line
in Tim Wilson's song "100 Things Every Man Needs to Know"

"You been married nine time? Hell, maybe it's you."

~~~
agentultra
I think then, that your correlation is imagined.

Yes, Lisp is a pretty powerful language but I don't think that has much to do
with its uptake (or lack thereof) in the mainstream.

You and the authors you cite have imagined this genius lone-wolf character
together. You harshly criticize the characteristics of this terrible phantom.
And then you conjecture that the lack of mainstream adoption of Lisp must be
accredited to this stagnant community of loners and miscreants. I assure you,
this straw man doesn't exist.

Maybe you've only met one or two in life that gave you a bad impression. You
should join #lisp and chat or email Peter Siebel and see if he fits into your
stereotype. You might find the experience enlightening.

To answer why there are so many Lisp projects with a single developer you will
have to answer why there are so few Lisp developers.

And here's a hint: It's not because the people who tend to like Lisp easily
fit into a simple, boring stereotype.

------
pg
Occam's Razor suggests that the reason there is no dialect of Lisp as popular
as less expressive languages is that no one happens to have created one yet.
What languages are has changed. Languages used to be specs. Now they're open
source projects. Open source projects seem to succeed based more on the energy
of their initial organizers than anything else. There are only a few big
language-project organizers, and none of them happens to have chosen to
implement a language that is a dialect of Lisp. That's the sort of thing
that's true until it's false. E.g. Clojure could be the counterexample.

 _Maybe_ there's more to it than a small sample size, but that seems the
likeliest explanation. The second most likely explanation is almost as
mundane: that the reason new dialects of Lisp have trouble attracting
adherents is that mainstream programmers are put off by s-expressions.

~~~
wheels
Another thing that's changed is _who_ is creating the dominant programming
languages.

In the programming-language-as-a-spec days, people versed in programming
language design created the dominant programming languages. In the
programming-language-as-an-open-source-project world, languages tend to be
created by people that are relatively clueless about language design at the
start (this holds for at least Perl, Python and Ruby). I don't know what the
root of such is, but there seems to be some negative correlation between the
design integrity of a given language and its popularity (for web hackers at
least – Java and C# adhere to the old model).

In contrast, Lisp seems to be fairly popular among folks that are programming
languages enthusiasts. So for whatever reason, there's a gap between the folks
that are creating new popular languages, and the sort of people that tend to
be Lisp fans.

The other bit is that, well, Lisp looks funny. This is something like someone
looking at a language that uses Greek or Cyrillic or Arabic alphabets and
assuming that they're by default harder languages because they use different
characters. In fact, a reasonably clever person can learn a new alphabet in a
day. It's a totally artificial barrier for someone who's serious about
learning the language since the investment to learn the new alphabet is
dwarfed by the work of actually learning the language, but it tends to make it
scarier if upon casual inspection. I suspect Lisp pushes some people away via
a similar artificial barrier.

~~~
InclinedPlane
I think the inverse correlation you've found is easily explained. There are
folks who design languages from the perspective of academia and there are
folks who design languages from the perspective of practicality, and there is
not much overlap in those communities. Perl and PHP are imminently practical
languages, but they never would have been put forth by academia, because they
are not pure, they aren't interesting in a research sense.

~~~
Locke1689
It's difficult to say that with complete conviction. Racket, for example, aims
to be very practical. However, most of the research in PL isn't necessarily on
entire new language systems as a whole, but maybe a specific feature or
category.

Disclaimer: I guess by association I'm affiliated with this group[1].

[1] <http://www.racket-lang.org/people.html>

------
TY
Most of the essay can summarized by this quote from it:

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

While this is not a bad essay I'm experiencing a fatigue from reading
articles/books/posts about great powers of Lisp and why Lisp is where it is
today.

Instead, I'd love to see that mental energy spent on
advocacy/defence/adulation/hatred of various Lisp dialects on actually writing
great software.

Let's stop looking at Lisp as a religion and instead use it as a great tool to
create beautiful things.

Disclaimer: I've used CL, Scheme and Clojure on my various (mostly personal)
projects. For the current one, I use Python as it fits better for what I'm
doing today. My next project will use whatever it needs to work.

~~~
winestock
"I'm experiencing a fatigue from reading articles/books/posts about great
powers of Lisp and why Lisp is where it is today."

So am I. I wrote the essay because this idea has been banging in my head for
some time and I had to let it out. The urgency shows in places. Elsewhere in
this thread, others are pointing out that I don't know that much C. Guilty.

Another commenter's suspicion about the "we lost because we're so awesome"
theme also has merit. I suppose that Lisp _must_ have some intrinsic problems,
but reading about the Lisp Machine period makes the language so enchanting.

~~~
lkesteloot
I've always suspected that Lisp is write-only. For example, it fails the
squint test, which I wrote about here:
[http://www.teamten.com/lawrence/writings/the_language_squint...](http://www.teamten.com/lawrence/writings/the_language_squint_test.html)

Being write-only would explain why there are so few collaborative Lisp
projects.

And I don't particularly buy the thesis of this essay that there are few
collaborative Lisp projects because it's possible to do anything with a single
person. You can always find sufficiently difficult problems that would require
a team. Projects in Lisp should be putting projects in other languages to
shame. I think there's something about Lisp that makes collaboration too
difficult, and I suspect it's the expressiveness itself.

~~~
spacemanaki
I dunno, I don't really buy your squint test for languages. While it makes
some sense for graphical user interfaces, (most) source code isn't graphical,
it's textual, and you wouldn't apply the squint test to the arbitrary written
word, would you? Where every page of every book looks the same...

~~~
lkesteloot
It's true that I wouldn't apply it to prose, but that doesn't mean it's not
useful for code, where you often want to look at lots of it and get a gist of
what it's doing. Also I often do think of a programming language as a user
interface, even if it's not actually made of buttons and icons.

I'm not claiming this is the main problem with Lisp; only that it's one of
them.

------
luu
I’m always wary of arguments along the lines of “we weren’t successful because
we were _too_ awesome”, when there are alternative explanations. Could there
possibly be any other reason?

I’ve found Ruby to be very easy to extend, and one complaint I’ve heard is
that it’s so easy to write DSLs that everyone has their own incompatible
languages. And yet, Ruby is successful. So, how come Ruby is more marketshare
than, say, SML? Could it possibly be that most people just find it easier?

 _It implements most of the unique features of Haskell and OCaml. In some
respects, Qi surpasses them. For instance, Qi's type inferencing engine is
Turing complete. In a world where teams of talented academics were needed to
write Haskell, one man, Dr. Tarver wrote Qi all by his lonesome._

Seriously? Qi is nice, and “better” than Haskell and Ocaml in some respects,
but it’s also inferior in many other respects. To port all of Haskell's
experimental features to Qi would require teams of people. There's nothing
particular to Lisp that would make that orders of magnitude easier. Haskell
just has a lot of features.

~~~
silentbicycle
> So, how come Ruby is more marketshare than, say, SML?

How much of that still applies if you take away Rails (and all the marketshare
that came from it, and all the resulting tools, etc.)? Having a killer
application makes a big difference.

The killer application of SML seems to be teaching, and awesome compiler
research. With all due respect to SMLers, that's much less likely to interest
hordes of average web developers.

~~~
protomyth
Separating a language from the things you build in it kinda misses the point
of the language. Ruby inspired / allowed Rails. Sadly, Lisp and SML haven't
have powered anything of similar popularity.

~~~
dwc
And I think this is what the author was saying. In Lispland you don't get
something like Rails, you get a bunch of 80% solutions, all different.

------
randrews
I see his point about how everyone rolling their own thing is bad for the Lisp
community, but he's got a kind of ridiculous view of C:

"Making Scheme object-oriented is a sophomore homework assignment. On the
other hand, adding object orientation to C requires the programming chops of
Bjarne Stroustrup."

It really doesn't. You can have a system that uses structs with function
pointers, which is how things like Glib work. You can have a compiler that
adds special syntax for doing this, which all gets translated into normal C
calls; this is how Objective C works. OO is just Not That Hard To Do in any
language.

Anyway, Lua is another great example of this curse because there's no module
system or standard library to speak of, everyone rolls not only their own
object system but their own list functions. The reasons are different though;
Lua's design goals are to be a tiny language for embedding, so they sacrifice
completeness for being really easy to customize.

~~~
haberman
I agree that basic OO is easy, but inheritance (particularly multiple
inheritance), virtual functions, RTII, etc. add _significant_ complication.

~~~
randrews
It's more complication in design than implementation though, and doing it in
Lisp instead of C won't help that any. Once you decide what you actually want
to write, it's not a whole lot harder to write it in C than Lisp. It's harder,
but it's still something that anyone who can do it in Lisp would be
comfortable doing in C.

------
shasta
Or the explanation could be that Lisp just isn't that great. First of all, it
doesn't even make much sense to talk about "Lisp" as if it's a language. The
difference between the toy lisp you can write an interpreter for in a page of
code and Clojure is night and day. And the other features are actually much
more important than just being a Lisp. I'd be afraid to work with the
"Haskell" that the smug Lisper of the article slaps out with macros. Not only
would it probably not be as well designed as Haskell, unless they copied
Haskell's hard work wholesale, but it wouldn't interop well with any other
Lisp code.

Secondly, if you actually look at the defining feature of Lisp, S-Exprs and
macros, it's not a good idea. Code generating S-exprssions may be more sane
than generating C code through string manipulation, but it's still a bad idea
and for the same reasons. Code is a human readable format (even if you force
it to be S-expressions and pretend it isn't). Code shouldn't be generating
other code, it should be generating more structured values. There are
composability advantages to doing so and as an added benefit, you don't get
stuck with S-expressions as syntax. I predict that in the not too distant
future, languages will provide a better alternative to almost every current
use of macros (we're already over half way there).

~~~
winestock
I think that you're the only person in this thread who openly questions the
cheer-leading of Lisp. I respect that. For that, I gave you an upvote.
Heretic.

Sure, the pile of Lisp macros that recapitulates most of Haskell would be
gnarly and nasty. But would that be due to the intrinsic bogosity of doing it
through macros, or would it be due to it coming from a lone hacker who's
following the scratch-an-itch school of design?

 _Code is a human readable format (even if you force it to be S-expressions
and pretend it isn't)._ Here's something for which there's no accounting, as
the Romans used to say. Plenty of smart people love S-expressions. Plenty of
smart people can't stand them. John McCarthy thought that S-expressions would
go away, but no one got around to that in more than half a century. Someone
must find them readable.

 _Code shouldn't be generating other code, it should be generating more
structured values._ You must know more than me. Something more structured than
code?

~~~
shasta
I think the reason that S-expressions haven't gone away is mostly because of
the way they mesh with macros, but anyway the sub-optimality of S-expressions
as a syntax wasn't a part of my argument there (I don't like them, but I don't
hate them). In that quote, I meant there that all code, even S-expressions, is
a human readable expression that defines the thing you're interested in.

Note that it's considered poor form in Lisp to make a square macro that
multiplies its parameter by itself. That should be a function. Why? Because
numbers have the structure you want them to have. A function that takes a
number and multiplies it by itself is just simpler than a function that takes
an expression for a number, and pastes it together with an astericks and then
returns that to be evaluated. And because the function has a better structure
than a macro, it's more composable.

The thing is that this same situation exists with most other uses of macros.
In a language with staged computation and maybe a little well tamed syntax
extension, I think there would be no place for macros. You can do better.

~~~
Dn_Ab
I really like what they are doing in Nemerle 2.
<http://code.google.com/p/nemerle-2/> (Not associated in any way)

------
mtraven
As someone who has programmed Lisp commercially for a long time, I have to
agree with this essay. I've had much the same thoughts over the years.

At one point I was one of five Lisp engineers in a 10-person company. I think
we had no fewer than five hairy macros for creating complex UI layouts,
because everybody wanted to do it their own way, and you could hack something
like that out in an afternoon.

You'd never get the same kind of phenomenon in a Java-based project, because
creating something like that in Java is a major undertaking, so you'd have
people settle on one that probably came from outside, and a whole ecosystem of
sponsors, books and whatnot.

Just very different worlds. But Lisp programmers can't reinvent the wheel all
the time, so I'm very glad of things like Cliki, asdf, and Quicklisp that are
promoting sharing and standardized libraries.

~~~
dwc
I would like to ask you about this:

    
    
        I think we had no fewer than five hairy macros for
        creating complex UI layouts, because everybody wanted
        to do it their own way, and you could hack something
        like that out in an afternoon.
    

Even though I have worked in commercial environment _other_ than Lisp (never
Lisp so far), there are lots of things that can be hacked out in an afternoon.
Yet having five hairy sets of duplicated functionality is something I'd never
let stand for long. It seems to be a culture thing rather than a language
thing. Is that right?

~~~
mtraven
I don't think you can separate language and culture so cleanly.

Oone of the attractions of Lisp is that you can mold the language so its just
the way you like it. That makes it harder, sometimes, to have a group come to
a consensus about the way things should be. It's just a tradeoff.

As somebody else pointed out recently, highly empowered individuals can be a
downside from a management perspective, and that perspective is _not entirely
wrong_ , although it's maybe not the way hackers think.

~~~
kenjackson
_It's just a tradeoff._

But it's a tradeoff that has left Lisp with one major app in 40 years (Emacs)?
A handful of notable apps... and that's it.

And why, in a space like phones, where one dev can produce an app in a week to
months, are there no incredible Lisp applications? This seems like the perfect
domain where one to three devs is all it takes to make a world-class app, and
theoretically with the awesomeness discussed in the story we would expect at
least one Lisp app that was just mind blowing. Of course that hasn't happened.

IMO, what I think happens are those people who are attracted to Lisp are those
who like language purity/elegance and bask in it. They tend to be those that
over-attribute the power of a language to the productivity of a developer.
They have a great language, and are bright people, yet the result is nothing
beyond the normal range of expected output. So they then try to create a
rationale that combines their belief that they have a super language, with
some odd external force that keeps that language from showing its true power
to the outside world. Missing perhaps the most obvious thing which is that in
terms of expressability/productivity, language is probably a 1.5x multiplier
at best. But if they concede that the multiplier on productivity isn't at
least 10x, they may have to admit that the beauty of the language is mostly a
form of self-gratification.

~~~
mtraven
Well, there are more than a few, but they tend to be highly specialized,
knowledge-intensive apps that you've never heard of. Here's a list from one
Lisp platform vendor -- I've worked on several of the projects listed there:
<http://www.franz.com/success/all_customer_apps.lhtml>

Then there's ITA, recently acquired by Google, I assume you've heard of them?
All Lisp, as far as I know.

~~~
kenjackson
I'd put ITA, ViaWeb, and a handful of others in the notable category. Although
all I know about ITA is what they do (at a USA Today level), its Lisp (at the
very least a large majority), and that they were bought by Google. Maybe ITA
can be promoted to the Emacs level?

That vendor list is a nice reference, but I wouldn't be surprised if the D
programming language vendor list was near that size. And no one uses D. Just
imagine a similar list for virtually any other language commonly discussed on
HN, from C/C++, to Java, C#, Python, Ruby, Javascript. I'd be surprised if
Smalltalk wasn't 10x the size.

Don't get me wrong, I think its a great language. I just don't think any
language gives the benefits that so many people seem to think they do, at
least not general purpose languages. DSLs? Sure, they can give huge
multipliers -- in their domain or maybe even for a specific domain. But not in
general (and maybe those knowledge-intensive apps are those for which the
multiplier is higher).

------
ChuckMcM
An alternative explanation is that Lisp doesn't have a person with a strong
vision, program management skills, a thick skin, a diplomatic way to saying
no, and a big ass repository.

The same argument is repeated throughout the essay, "Its not that Lisp doesn't
have X, it has {X0,X1,..Xn)!" and that is the problem. Using lisp I get no or
very low re-use for any code out there. Ergo I must write a lot of it myself.
He recognizes it and laments:

"Look more closely: Large numbers of the kind of people who become Lisp
hackers would have to cooperate with each other."

At the solution. But here is the rub, the qualities of the lisp user today
are, in part, derived from how difficult it is to re-use code. People who
could write anything they wanted enjoy the expressive power of lisp and
tolerate the requirement to create from whole cloth basic things that should
exist already.

Now posit a world where there was the Lisp equivalent of CPAN, and an
aggressive authoritarian requirement on documentation, coding standards, and
unit testing. Once sufficient mass had built up in this repository, even
dweebs who don't know the difference between arrows and monads could use Lisp
to make something useful, and they would take on the false mantle of 'lisp
hacker' and the population of lisp users would swell and there would be still
more things checked in and poof a thriving 'lisp' community, except it
wouldn't look at all like the current community.

~~~
jleader
You make it sound like CPAN has "an aggressive authoritarian requirement on
documentation, coding standards, and unit testing" (or at least that Lisp
would need that to make a hypothetical LPAN successful).

CPAN definitely does not have that. What it does have are fairly strong social
pressures in favor of those things, and extensive frameworks making it easier
to provide those things (I'm thinking in particular of cpantesters.org
providing free cross-platform unit testing support for all of CPAN).

------
schickm
Oh lordy...this essay effectively summarizes the entire codebase of the lisp
application that I work on with a team of 6 or so other developers.

I think what can work though is having an awareness of the power of the
language you are working with, and then balancing the usage of that power with
readability of code. You can write macros all day that save you precious
typing time, but when someone else has to figure out those macros all that
saved time is lost. Any language that allows the developer to define the
syntax will always be troubled with this concept.

------
gphil
This idea kind of reminds me of the notion that ideas are cheap, and that
execution and hard work are what it really takes to create a valuable company.

It seems to me that the hard part of developing language features is
developing the documentation and the tools, and it's this work that will drive
language popularity much more than the features themselves.

------
gord
I suspect there are similarities to : Why aren't the smartest people the
richest, why dont they get laid the most?

The lisp language 'microkernel' is clearly a fundamentally important construct
- the essential core of all computer language.

But lisp needs to interact with the surrounding ecosystem - less than genius
level programmers, ugly APIs, non-mathematically perfect OO abstractions, old
fashioned data stores. Its actually a lot of work to wrap that... given the
impedance mismatch. Perhaps this is the same reason microkernel operating
systems have won in theory but not in practice - interfacing to 'the real
world'.

Comparing Arc and Scheme [both of which I really enjoy] to the Javascript /
node.js 'environment' ... it seems Node.js is more amenable to real work. Its
a less expressive / powerful / elegant language - but via Node, Javascript
melds beautifully with the async IO model of the OS and gives superb
primitives for developing TCP/http services.

Maybe its not the breadth of the libraries available, but the smoothness of
the bridge between the language and the real world.

Geeks who apply their smarts and learn something about social interaction do
get laid [ to abuse my analogy ].

------
magice
I think this essay is bull. As someone points out, it is yet another I-am-so-
good-that-no-one-wants-me things that LISP people love to throw out. Maybe
THIS attitude ("Lisp is Olympia and I, the proud user, is Zeus") is why.

Let's be frank, there are many many excellent languages that do not even
attract enough people to have a "community." Icon always comes to mind as
example: brilliant language, excellent libraries, but the only believers are
myself and a professor. Other than that, Haskell, SML, OCaml have never
attracted a significant number of users. They all are brilliant, right? BASH
may have more serious products than those great things.

Let's face it, the true Lisp curse has not been discovered, and Lispers'
attitude has helped it hide even better. I have my theories; you have yours.
And mine are always more correct than yours. It's Lisp land, man. You can't
argue against that.

~~~
ebiester
You, a professor... and about 15-20% of anyone who came out of the University
of Arizona over a decade or two. :)

I remember writing a java library to do SNOBOL/Icon-style pattern matching in
college because I hated the java way so much... every once in a while, I think
about doing it again.

------
ww520
Large cooperative programs are usually written once but read many times. For
large projects to succeed, the reading part needs to be optimized.

Lisp being too expressive encourages the optimization in the writing part - I
can write my own macros/DSL to make writing MY program easier. The readers
needing to learn and understand those are their problem. This encourages
people to write their own libraries instead of understand and reuse the
existing ones since it's always easier to build a mental model of your own
writing than the others.

As noted by the others, Scala is starting to have the same problem in
regarding in its ease of proliferating DSL.

------
kleiba
Not all professional programmers are college kids with degrees in C.S.
Imperative languages are much easier to get your head around than OO-languages
if you don't have a formal training. And lispy abstractions like map and first
order functions are even trickier. So I thought it's natural that the more
abstract a language, the more difficult it is for it to make it into the
corporate world.

~~~
stray
There's nothing preventing you from writing imperative code in Lisp.

~~~
Bootvis
That's true but if you want to learn Lisp (anything) well you will have to see
examples, talk with peers etc. Everyone discourages too much imperative code
in Lisp so this will be very hard to pick up on your own. So to be an
effective Lisp-learner you will have to grok map, first order functions and
what not.

------
jhuni
The beauty of Lisp is in its simplicity. Lisp has the simplest syntax in the
world, and the entire language is based upon five simple primitives.

All other mainstream languages complicate matters with operator precedence
tables, multiple operator notations (prefix, infix, postfix, postcircumfix,
etc), and many other syntactic weirdities.

The simplicity of the language makes it the _best_ language there is for
collaboration. Lisp is not to blame here - the community is.

A properly organized community can create standards for the use of macros to
prevent their abuse and standardize on libraries to prevent fragmentation.
Unfortunately, the Lisp community isn't well organized.

~~~
winestock
_Lisp is not to blame here - the community is.

A properly organized community can create standards for the use of macros to
prevent their abuse and standardize on libraries to prevent fragmentation.
Unfortunately, the Lisp community isn't well organized._

In other words, it's not a technical issue, it's a social issue.

------
plinkplonk
It is past midnight where I live and it has been a long day, and I am sure it
is my fault, but I am having some trouble identifying the central point of the
essay.

Is it something like "The curse of lisp is that it is too expressive"? Genuine
question. Please help.

~~~
winestock
Close. The Lisp Curse is "Lisp is so powerful that problems which are
technical issues in other programming languages are social issues in Lisp."
Lisp is so powerful that an individual programmer can do a lot more than he
could if he were using another programming language. This seems to encourage
fragmentation and provide less encouragement for cooperation.

~~~
plinkplonk
Thank You. Now I understand what you are trying to say but am having trouble
seeing the logic supporting that assertion.

How is lisp so much "more powerful" than (say) Haskell (or Erlang ) to such an
extent that problems which are technical issues in Haskell or Erlang are
"social issues" in lisp? It seems to be that without some serious convolutions
wrt "power" to fit a pre existing bias, lisp is hardly "more powerful" than
Haskell ,or SML (or erlang or smalltalk or J or even Lua).

Most of these lisp "power" comparisons _seem to focus on easy to beat up
languages like PHP or Java and not so much the better designed ones like
Erlang or Haskell_ , which have vibrant communities and plenty of interesting
software written in them. Is lisp really "more powerful" than Erlang? or
Mozart/Oz? or Haskell?

I suspect pg's ideas of language success depending on the energy of the main
Open Source contributor + mainstream programmers aversion to S-expressions may
be more accurate.

Maybe all we have to do is wait a year or two and see which of Scala or
Clojure dominate on the JVM. The founders of both are very talented and
energetic.

If you are right, Clojure should end up "more powerful" than Scala but having
(relative to Scala) this "problems which are technical issues in Scala are
social issues in Clojure" dynamic. I somehow don't see that happening though.

~~~
technomancy
> If you are right, Clojure should end up "more powerful" than Scala but
> having (relative to Scala) this "problems which are technical issues in
> Scala are social issues in Clojure" dynamic.

Part of that is because Clojure isn't starting from scratch when it comes to
conventions; there are strong admonitions as far as avoiding side-effects,
favoring composable functions over macros, and re-using functionality from the
JVM where appropriate.

------
coliveira
The reason Lisp programmers don't have a fancy IDE is that they don't feel the
need for it. Everyone that really understands what he's doing is using Emacs
or their own thing.

In a way it is similar for other languages. Why Ruby doesn't have something
like Eclipse? Because it doesn't need one. Even for C/C++, the only reason why
there is a Visual Studio is that there are so many entry level programmers
that will buy it. Experienced C programmers feel much more comfortable using
UNIX/gdb.

On the other hand Smalltalk programmers have an IDE because they need it: it
is just the way it works for Smalltalk.

~~~
bgruber
> The reason Lisp programmers don't have a fancy IDE is that they don't feel
> the need for it. Everyone that really understands what he's doing is using
> Emacs or their own thing.

Actually, I think that Emacs+Slime for CL is one of the fanciest IDEs around.

However, it's also been my (anecdotal) experience that many C++/Java-
programming Emacs users have no idea what kind of stuff these fancy IDEs do,
the same way most of those IDE users don't have any understanding of the kind
of text editing Emacs is capable of.

~~~
ramchip
You're right about Emacs+Slime being nice for CL, but I don't think Emacs is
very good for C++ and Java code. Visual Studio (and similar IDEs) have some
killer features: Intellisense/autocompletion that "just works", an extremely
good debugger, visual representation of the project structure, plugins for
refactoring, integration with Qt and GUI editors...

I'm mainly a C++ programmer, and yet I use Emacs for everything _but_ C++ (IRC
client, LaTeX or text editor, Haskell IDE...).

------
Tycho
The problem with this argument that I see is that Lisp can't make _everything_
easy - there will still be more advanced problems that take collaboration to
solve. Thus while other programmers band together to make simple web servers,
Lispers should in theory band together to tackle deeper problems. Which would
make it more competitive than other languages, not less.

------
systems
lisp needs a cpan

~~~
ohyes
<http://www.quicklisp.org/>

~~~
edw
By Lisp, perhaps he was referring also to Scheme and Clojure. Not everyone is
aware that they're Lisps, too. (Detailed rationale and citation needed.)

For Scheme, nothing's ever really gotten off the ground. Little more needs to
be said on the subject than "R6RS module system debacle." There are meta-
module systems for Scheme. I'm waiting for the _meta_ meta-module system.

Clojure, however, has <http://clojars.org/> and lein (and cake). I've found
that Clojure programmers are _way_ more prone to look for something that
exists and (perhaps mostly) fits the bill before rolling their own. I
attribute this not to Clojure programmers being smarter or better human beings
but to the relative ease of creating, searching, and resolving package
dependencies.

~~~
silentbicycle
The Scheme community is too fragmented for a _meta_ meta-module system to
work. Racket and Chicken both have decent module repositories, at least.
(Probably some others do, too.)

No meaningful experience with Clojure, but it probably inherits some library
culture from running on the JVM as well.

~~~
nickik
Clojure sure does. Look at something like maven. It has lots of features but
alot of people don't like it. All we needed in Clojure were some people to
creat good abstraction over maven and boom! we have a great package system.

If you want to live on something like the JVM you have to use all its powers
to the max because if you don't its weaknesses will be bigger then the its
benefits you get.

