The Lisp Curse does not mean that incompatible libraries exist. The Lisp Curse means that it's so easy for individual hackers to go their own way that getting them to cooperate resembles herding nuclear submarines (i.e., they all need to respect the same formidable power, there'll be plenty of internal politics, et cetera).

My opinion of Emacs being obsolete is one which I got from reading James Gosling, the author of the first Emacs that ran on Unix. I trust that he knows a thing or two on the matter and he didn't rest on his laurels after moving on. Besides, his description of Emacs matches the evidence of the senses.

The alternatives which you mention demonstrate the Lisp Curse rather than refute it, judging from their websites. Climacs doesn't seem to have been updated in nearly three years. Portable Hemlock doesn't seem to have updated in nearly seven years. MCLIDE is Macintosh only. Those three projects are either moribund or unportable, as predicted by the Curse.

> My opinion of Emacs being obsolete is one which I got from reading James Gosling, the author of the first Emacs that ran on Unix. I trust that he knows a thing or two on the matter and he didn't rest on his laurels after moving on. Besides, his description of Emacs matches the evidence of the senses.

So in other words, you have no direct experience with Emacs to compare it to whatever other programming environments you may or may not have used.

Thank you for wasting our time.

> My opinion of Emacs being obsolete is one which I got from reading James Gosling, the author of the first Emacs that ran on Unix.

Mind you he wrote an Emacs in C, complete with a faux-lisp interpreter. That more or less precludes him from being an expert in Emacs.

Keep also in mind he gave Java to the world, some would argue, well after it was obsolete (some people will sustain that Smalltalk 80 made Java obsolete in the early 80's, a full decade before its launch)

Writing Emacs, be it in C or whatever, is hardly a reason to not call Gosling an expert in Emacs, quite the contrary! But you might argue his approach to Emacs is not idiomatic or not consistent with the community and so on, if there is evidence for that.

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?

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."

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.

Perl5 has had many OO libs but that has not helped. It is when the community standardizes on best practices and standard libs,such as DBI, that you get big advancements. Recent community efforts around "Modern Perl" and the Strawberry Perl distro are helping the language stay strong.

Another example is JavaScript's recent big leaps forward stemming from the community's embrace of jquery and the best practices from "JavaScript: the Good Parts".

Standards allow others to confidently build bigger and better abstractions. Which is the only way to build increasingly complicated software.

I beg to differ -- would Moose have surfaced had there not been a competing ecosystem of implementations? Of course it's impossible to determine, but my theory is that it takes competition to discover new ideas. It's not often you land on the obvious solution on the first try.

A more concrete example would be the standardization process of Common Lisp. Wouldn't have happened if there was not a vibrant eco-system of competing Lisp implementations. Eventually many of the ideas championed by the major implementations made their way into the CL standard. Now we have a new ecosystem of implementations and a standard for them to follow.

You can implement your own OO system in Python with metaclasses. Perl makes it easy to roll your own, while Python discourages doing so. Compare Perl's TMTOWTDI vs. Python's "There should be one—and preferably only one—obvious way to do it."