I find this to be unnecessarily prescriptive, as are almost all purely semantic assertions about what should be (semantic used in its weak, normal language sense here). It is certainly true that Schemes and Clojures and Adders and Emacs Lisps and so on differ in many respects from "Common Lisp" but that hardly justifies fixing the label "Lisp" to refer only to Common Lisp. I mean _Emacs Lisp_ contains Lisp in its name! Would you claim Emacs Lisp is not a lisp?
It remains that these languages have more in common with one another they they have in common with, say, Ada or Standard ML, but even were it not the case, so long as a listener understands what a speaker means when they refer to a language as being "a lisp," I see no problem with the continued usage. Language works when it allows communication, and as long as a word clearly denotes a concept in common parlance, it hardly needs to be dictatorially controlled. If people were referring to Clojure as a "Common Lisp," it would be useful to correct them, but this is not the case.
Vague language can even be enlightening, as it forms the nucleating body for useful discussions. For instance, one might pose the question "Is Ruby an Acceptable Lisp?", and while the answer is obviously, stridently, hilariously, no, the discussion will help illuminate what both terms mean.
So I favor letting language do its job, and letting lisp continue to refer, as an improper noun, to a cloud of languages sharing a family resemblance.
I would agree with you, if the notion of Lisp was actually well-understood. But, unfortunately, I observe the contrary very often. That's exactly why I've wrote this rant.
> It's not so much a question of "Why Lisp?" as it is a question of "Which Lisp?," if you ask me.
I can't imagine a similar question about C: "Which C would you use, gcc or clang, C++ or Java?" Can you? And that is because everyone understands what is C. Yet, I think, this understanding won't impede people from discussing something in the lines of "Is Go an acceptable C?" Just because C is so well understood you can clearly reason of it. But if you will say, that you use Lisp in a broad sense, this won't tell anything about your project, because it can be a very functional Clojure entangled with a lot of Java, or very academic and "pure" Scheme, or Common Lisp, or some obscure and very different dialect, like Nu or newLisp, or you've added your own "Lisp" dialect into a project... This doesn't help understanding, and it so happened, that there so many misconceptions about Lisp, that you have a hard time discussing it with people: first you have to educate them.
Speaking of Emacs Lisp. Indeed, it is a Lisp, and it is, actually, very similar to Common Lisp, just a more dated version, lacking some of the current Lisp features. But this case, likewise the case with AutoLisp, isn't a problem, as everyone can clearly draw a line between a general-purpose language and an embedded environment.
But the question "Which Lisp" is entirely meaningful, more so than even the question, more acceptable by your definitions, "Should I program in in Emacs or Common Lisp?" The programmer asking "Which Lisp?" might very well find that Racket is the language he wants or that Clojure is, since both are similar in capabilities to Common Lisp. The question meaningfully indicates confusion. A person wants to write a real program in a language with s-expressions and a macro system, probably, and any of the languages listed satisfies those goals, and the discussion will focus on the ways they differ. This seems fine to me.
The question should you program in Emacs Lisp or Common Lisp is meaningless. If you program for Emacs, you use Emacs Lisp, otherwise — Common Lisp. It would be very hard for you to do it the other way. I, actually, wonder how much knowledge about Lisp do you have, since you pose such question.
Regarding the question "Which Lisp?", it wasn't appropriate in that discussion, as the article was clearly about the use and features of Common Lisp. It was not discussing how an S-expression-based macro-language was a very good choice. To reduce the essence of Lisp to a simple notion of s-expressions + macros is a huge misconception, that I'm fighting here. Lisp is much more than s-expressions + macros. The proper question would be "Which S-expression-based language I want to use?" And posed in such way you should clearly see, that it is not a fit for this discussion. It would be much better, if everyone understood well the full feature-set of Lisp :)
My point was exactly that the allowed usage you propose, where Emacs Lisp is a Lisp and Clojure, for instance, is not, is quite ridiculous. The disallowed usage, "Which Lisp should I use, Clojure or Common Lisp?" is however, not ridiculous. Your rule excludes a meaningful usage and includes a ridiculous one.
I'm not saying that Common Lisp reduces to s-expressions and syntax extension or even that "lispness" does, only that s-expressions and syntax extension are the features to which the denotation "a lisp" most frequently refers.
Incidentally, I program in Common Lisp for a living and am the author of several libraries in several lisp dialects, which, while not enjoying much use, do demonstrate a working knowledge of the language family. But thanks for imputing my qualifications.
I don't think, that the question "Which Lisp should I use: Clojure or Common Lisp?" is quite correct. As they are really so different in very basic concepts: mutable vs immutable, OO vs non-OO, bootstrapped vs JVM-based, and the list can go on and on. This question is of the same sort of "Should I use Lisp (I mean Common Lisp) or Python?" And it can be reduced t "Which dynamic language should I use?" Or "Should I use Lisp or Java?" - "Which memory-managed system programming language should I use?" Likewise "Should I use Lisp or Clojure?" can be reduced to "Which s-expression based language should I use?"
For me the word Lisp means the very simple abstract language that McCarthy designed (no implementation details etc). Common Lisp took those concepts, added many more of its own and became a standard. Scheme and Clojure took the same approach, take the very basic elements of Lisp and add their own concepts on top of it. So, calling Common Lisp the only Lisp just doesn't make any sense at all.
What has the author exactly achieved compared to, say, pg or Rich Hickey?
Here's an answer from Rich Hickey about the type of person such as the author of TFA:
Q: What would you say to people who claim that Clojure is not a “real Lisp”?
Hickey: Life is too short to spend time on such people. Plenty of Lisp experts have recognized Clojure as a Lisp. I don’t expect everyone to prefer Clojure over their favorite Lisp.
We understand you, author. You love your CL and you think it's the one true Lisp dialect. Good. We have no time to waste with you ; )
It remains that these languages have more in common with one another they they have in common with, say, Ada or Standard ML, but even were it not the case, so long as a listener understands what a speaker means when they refer to a language as being "a lisp," I see no problem with the continued usage. Language works when it allows communication, and as long as a word clearly denotes a concept in common parlance, it hardly needs to be dictatorially controlled. If people were referring to Clojure as a "Common Lisp," it would be useful to correct them, but this is not the case.
Vague language can even be enlightening, as it forms the nucleating body for useful discussions. For instance, one might pose the question "Is Ruby an Acceptable Lisp?", and while the answer is obviously, stridently, hilariously, no, the discussion will help illuminate what both terms mean.
So I favor letting language do its job, and letting lisp continue to refer, as an improper noun, to a cloud of languages sharing a family resemblance.