If you want to do a really poor, minimal job of implementing something that processes and executes programs, you will find that most of the complexity will rest in handling syntax. Any reductions in that complexity will have a big relative impact on trimming down the code and amount of work.
Now you can duck out of implementing solid semantics, without changing what a language looks like. For instance, programs language with broken scope can look superficially like programs in a language with working lexical scope. Or, a language that works by interpreting a syntax tree using a few lines of code looks and works just as well as a compiled one, just slower.
But if you don't negotiate about what a language looks like, there is only so much simplification you can do while still correctly handling the syntax which allows the language to look like that.
Further reductions in complexity require simplifications in syntax (how the language looks), which leads toward one of several existing well-understood design families for minimal syntax: Lisp-like, Forth-like, APL-like.
I've implemented things with "Lisp syntax" a couple of times, neither of which had anything whatsoever to do with Lisp. I used to call it the "Lisp non-syntax".
Nowadays I usually bite the bullet and just use JSON or something, but if you want to implement an interpreter starting just from bare minimum string functions pretending you're in 1980 and can't just grab half-a-dozen serialization formats out of your language's package manager (not a bad thing to practice!), Lisp-non-syntax is still a pretty good choice.
Well, most mainstream languages are dialects of Lisp (though usually with syntax, records, methods, and sometimes static typing) so if you strip them down far enough you get Lisp. Other reasonably usable minimal programming languages do exist, like the lambda-calculus, the pi-calculus, Abadí and Cardelli's object calculus, the ur-Forth, and the ur-Smalltalk, but they're not as familiar.
Garbage collection was developed for Lisp.
That way, any language with GC borrows directly from Lisp.
Lisp introduced the notion of Symbols, which is just String Interning. That way, any language with String Interning borrows from Lisp.
REPL based development was Lisps forte. Any language with a REPL borrows directly from Lisp.
Anonymous functions are a feature of Lisp since 1958. Any language with Anonymous functions is a descendant of Lisp.
I could go on, but we are not exactly talking about syntactical lookalikes but semantic lookalikes too. Java, C# with LINQ, Python, Perl, Ruby, Julia, Common Lisp, Clojure, ML family, Rust hygienic macro system (from scheme), C++ anonymous functions ... almost everything takes a lot of features originally started by LISP
>Garbage collection was developed for Lisp. That way, any language with GC borrows directly from Lisp.
The English language borrows a lot of things directly from other languages. That doesn't mean it is "a dialect of" any of them, which was the claim being objected to–that "most mainstream languages are dialects of Lisp".
Programming languages are not natural languages. The usual definition (which is loose) of a dialect in natural languages does not actually apply on "programming languages", which I repeat do not even classify as natural language.
Comparing our natural definition of a "dialect" to a PL definition of a dialect is erroneous.
I will not defend the parent's use of the word dialect anymore, and I think "decedent" is the right word to go.
More like that some English users will claim that their language is a Lisp dialect. Which then actual Lisp users will find controversial and they will get attacked as having no clue.
English is a dialect of Proto-Indo-European. It has enough of a mix of features from Latin and especially French that I wouldn't be comfortable calling it a dialect of Proto-Germanic or Old Norse; but nobody would ever confuse it with a Sinitic or Semitic tongue. In the same way, C combines features of Lisp, such as recursion, the heap, and conditionals, with features of FORTRAN and COBOL, like static types, nested records, and statements.
Spanish, by contrast, is clearly a dialect of Latin, despite the presence of articles, and in the same way Python and JS are dialects of Lisp.
You're confusing languages "descending" from others and dialects (varieties of a language). It's true that there's not a strict boundary between dialects and languages but thinking English is simply a dialect of Proto-Indo-European is muddy. The better version of the argument is that English is a dialect of Indo-European. Proto-Indo-European would be the variety of Indo-European spoken at a particular time (though it's in fact entirely reconstructed). To follow the linguistic analogy, popular programming languages are creoles (like English). They combine features of multiple languages.
Right! Also conditionals (if-then-else), recursive functions, dynamic typing, and eval all originated in Lisp in 1959. The first two of these are even in C.
http://www.paulgraham.com/icad.html goes into some details. In http://canonical.org/~kragen/memory-models I go into some details on how the Lisp memory model is the basis of, for example, Java, and what some of the alternatives look like.
Now you can duck out of implementing solid semantics, without changing what a language looks like. For instance, programs language with broken scope can look superficially like programs in a language with working lexical scope. Or, a language that works by interpreting a syntax tree using a few lines of code looks and works just as well as a compiled one, just slower.
But if you don't negotiate about what a language looks like, there is only so much simplification you can do while still correctly handling the syntax which allows the language to look like that.
Further reductions in complexity require simplifications in syntax (how the language looks), which leads toward one of several existing well-understood design families for minimal syntax: Lisp-like, Forth-like, APL-like.