"I think there's something about Lisp that makes collaboration too difficult, and I suspect it's the expressiveness itself."
That goes back to the point of the essay. The expressiveness of Lisp encourages, among other things, the creation of a "little language" for each project. This makes collaboration more difficult. Ergo, it's a social issue rather than a technical issue.
Okay, I see what you mean by that now. I might still quibble that calling it a "social issue" (as opposed to technical) makes it sound like it's not Lisp's fault. A good feature that leads to a bad situation is a bad feature. I want to call out macros for what they are: a feature that contributes to Lisp not being used.
Thinking about it more, I might describe macros as "anti-social" in that they help the programmer but hurt the team. This might be what you meant.
Note that I'm not saying that the idea of macros is bad; only that Lisp's decision to make them look like function calls is bad. I once saw a macro system for Lua that made their invocation look clearly different than normal language.
> A good feature that leads to a bad situation is a bad feature.
Pretty much every technological advancement ever has made it easier for people to get themselves into bad situations (and some people have indeed gotten themselves into bad situations). Cars enable you to move very fast, which enables you to crash and die, and many people have done just that. Clearly, cars have "led" to car accidents, which are surely "bad situations". But would you recommend eliminating or crippling cars for this reason? I don't think so. The solution is for the people who use these tools to become mindful of these dangers, not to get rid of the tools.
... Perhaps you could find some way to make the tools safer without crippling them, and, sure, that would be nice. But what you said was that it was a "bad feature", implying that in the absence of any creative alternative ideas (to remake the feature so that the risks are mitigated while the functionality is retained), it should be thrown out. And in that case, my rebuttal stands.
"The solution is for the people who use these tools to become mindful of these dangers, not to get rid of the tools."
Sure, but after 55 years of Lisp, that hasn't happened. If Lisp is unused because programmers find it hard to resist using a feature anti-socially, then it's time to change that feature.
Of course I have no hope that Lisp will change its macro feature. My interest is in making sure that new language designers realize that Lisp's so-called perfection is the very reason that it languishes.
That goes back to the point of the essay. The expressiveness of Lisp encourages, among other things, the creation of a "little language" for each project. This makes collaboration more difficult. Ergo, it's a social issue rather than a technical issue.