...it seems to me all programming languages, including Lisp implementations like CL and Scheme, are mere instantiations of Lisp...
There's an element of truth in that, but only in the same sense that all Turing complete programming languages are equivalent or that many programming languages are ultimately instantiations of a register machine, a memory store, and a program counter. The interesting thing in most cases is what you build on top of that foundation.
With Lisps, the value is in the uniformity. That makes it very easy to extend the basic functionality you get out of the box in a way that fits in, using macros and so on.
With various other languages, the value is in the pre-built tools that rest on top of some underlying abstract syntax tree. That covers a vast range of functionality these days: more expressive type systems, a wider range of built-in data structures, actor-based concurrency, low-level memory and port access, and numerous other practically useful language features. Hopefully any given language offers a combination of features that work well together and have natural supporting syntax and semantics. That in turn gives each language its own flavour and means each language works better for some types of software than others, even if ultimately it's usually just syntactic sugar for a relatively simple execution model and an AST.
Two things: both mtts and Silhouette are expanding on what I meant (rather than what I wrote):
McCarthy's Lisp:{Python,Ruby}::zygote:adult human
mtts as quoted by Silhouette gets it right IMO. Conversely, S's distinction between extending a language and using the tools (the distinction, to oversimplify, that makes you a Lisp programmer) that sit on top of its core seems to me a confusion of means with ends. Any useful program is a fall from the perfection of JM's insight. This perspective makes me a not-Lisp-programmer. Thousands of developers smarter and more experienced than I have taken each side of this dispute without resolving it; I certainly don't hope to.
I think perhaps you're suggesting a false dichotomy there. Almost any useful general-purpose programming language is going to have both some degree of extensibility and some degree of support from built-in language features. The different flavours are a question of priorities, because the more specialised tools you provide via dedicated language features, the harder it is to keep the core of your language generic. The really successful languages tend to have a set of specialised features powerful enough to give a significant advantage over languages without them, but well enough matched and with clean enough semantics that the overhead for extensibility in other directions isn't prohibitively increased.
There's an element of truth in that, but only in the same sense that all Turing complete programming languages are equivalent or that many programming languages are ultimately instantiations of a register machine, a memory store, and a program counter. The interesting thing in most cases is what you build on top of that foundation.
With Lisps, the value is in the uniformity. That makes it very easy to extend the basic functionality you get out of the box in a way that fits in, using macros and so on.
With various other languages, the value is in the pre-built tools that rest on top of some underlying abstract syntax tree. That covers a vast range of functionality these days: more expressive type systems, a wider range of built-in data structures, actor-based concurrency, low-level memory and port access, and numerous other practically useful language features. Hopefully any given language offers a combination of features that work well together and have natural supporting syntax and semantics. That in turn gives each language its own flavour and means each language works better for some types of software than others, even if ultimately it's usually just syntactic sugar for a relatively simple execution model and an AST.