← Back to context

Comment by ChuckMcM

15 years ago

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.

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