Where is it, then? Where is the final, perfect Lisp that's so easy to write?
What you seem to be saying is that being smart automatically makes people good at language design. And you are just dead wrong. Being smart may make you a good language implementor, but there's little correlation between that and the kind of skills you need to be a good language designer. Some of the worst languages in the world were designed by smart people.
It's a big problem when your users are contemptuous, because that means they don't need your project.
The Arc users on arclanguage.org don't seem that contemptuous.
So instead of doing things with the language, they do things to the language.
That seems a good sign to me. Munging the language is what you do with Lisp, like numerical calculations are what you do with Fortran. So what this means to me is that the users are real Lisp hackers, using the language as Lisp is meant to be used.
Plus I explicitly said that at this stage I'm mostly interested in the core language, and that I want to hear new ideas in that department.
Maybe there isn't a final, perfect Lisp. Maybe there are lots of individual Lisps that are each perfect for some class of problems. That's one of the great strengths of Lisp: if an existing implementation is almost-but-not-quite what you need, you can throw a few macros on it and adapt it into a new language that is what you need.
It's one of the greatest weaknesses too: you don't see the same willingness to say "This is good enough; let's move on to more interesting problems" that you get with, say, Python/PIL or Ruby on Rails.
If you're going to create a new Lisp (and expect people to use it; creation for the sake of creation is another thing, and doesn't need justification), you've gotta answer why it's superior to throwing a few macros on top of an existing Scheme or CL implementation. After all, wouldn't an individual programmer know his specific problem better than you do? They don't have to worry about harmonizing a variety of concerns, because they don't have to worry about other people's concerns. They could just build the language that's best for their specific problem and keep it in their own private toolbox.
This is actually what causes that disparity between what people think of new technology when it first comes out and two years later, as long as it still exists: one party was busy developing, the other party was busy coming up with reasons it can't be done, getting pats on the back for being so smart, then riding that dopamine rush to nowhere fast for two years until they meet the product again and just say "oh, I was wrong." Then this cycle continues. That's what PG's essay is about.
But being unable or unwilling to argue semantics does not make the original poster's ideas wrong. The only way to prove a determined person wrong is to engage in direct competition, and from the rear, of course, as the other party is already ahead of you. For obvious reasons, it's easier and "smarter" to come up with "logical" reasons than to "do the full experiment" to show it's wrong. We're not talking about math equations here, so a productive person's potential is more than his writing but also his skills, experience, credibility, and dedication, which can't all be ignored.
If that were true, Scheme and CL wouldn't exist themselves. Everything you can do in those languages you could have done by writing a few macros on top of their predecessor, Maclisp.
What you seem to be saying is that the evolution of programming languages has now stopped. No one ever needs to make a new LFSP, because SPs can do whatever they need by writing macros on top of existing languages. Do you realize how unlikely this is, historically? Especially in a field like programming languages, which is at the moment in a period of ferment.
If you think CL is the last word in Lisp, you probably have a higher opinion of it than any of its designers. They were in the kitchen when it was being made, and they are all too aware of all the hacks and kludges that went into it.
I don't think a comma is required after 'it'.