Comment by agentultra
15 years ago
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."