Newcomers are always confused by the distinction, this doesn't help at all to put them in the same big bag. This classification is not wrong, but mostly useless when you see how the different "dialects" evolved (they are grown-up languages, nowadays).
> C is a language, not a family of languages that includes Rust and Go.
But Rust and Go are constantly compared to C. We always talk about C-like languages. Maybe I should have said "Algol" instead, but there is a family of languages rooted at "C", and we don't call it the C family.
Go is "a compiled, statically typed language in the tradition of Algol and C". "The syntax of Rust is similar to C and C++", but "Rust is semantically very different from C and C++.[citation needed]" (wikipedia).
Likewise, Scheme is semantically very different from Common Lisp. And Racket is not considered as a Scheme, even though it is related to it. You can't copy-paste any Typed-Racket expression and run it with ChezScheme.
So, yes, they all belong to the same proto-language family, but constantly referring to them as a unique family is doing a disservice to each of them.
Take Clojure for example: the wikipedia page says that it is inspired by C++, C#, Common Lisp, Erlang, Haskell, Mathematica, ML, Prolog, Scheme, Java, Racket and Ruby. There are plenty of influences that goes into a language, why not talk about the other ones? parentheses?
> So, yes, they all belong to the same proto-language family, but constantly referring to them as a unique family is doing a disservice to each of them.
This is like saying that referring to dialects of English as "dialects" is doing them a disservice. If you are studying them, it is, if you are learning English as a second language, it is not.
If you look close enough, the differences are huge (after all, that's why someone created a specific lisp dialect in first place), but from a distance, they are all still pretty similar.
And finally, I rarely witnessed any discussion about those differences among lisp programmers, they were merely referred to when discussion how to implement something: "X-style Y", where Y is some CS-concept and X is some lisp dialect tailored to Y - and implementing anything in your preferred dialect is usually "trivial", though not necessarily performing as well as the implementation in some dialect tailored to the task.
> Newcomers are always confused by the distinction, this doesn't help at all to put them in the same big bag. This classification is not wrong, but mostly useless when you see how the different "dialects" evolved (they are grown-up languages, nowadays).
Sadly, language is determined by usage, which only incidentally correlates to usefulness. And critically, there's a feedback loop here: a word is only useful as it's used, because otherwise people don't know what it means, and you've failed to communicate your intent. "Lisp" might hypothetically be more useful if it meant "Common Lisp", but it's not useful for meaning "Common Lisp" (at least not on Hacker News) because when you say "Lisp" people assume you're talking about all the languages with the parentheses, and you've failed to communicate.
> But Rust and Go are constantly compared to C. We always talk about C-like languages. Maybe I should have said "Algol" instead, but there is a family of languages rooted at "C", and we don't call it the C family.
Right, the terminology commonly used for that is "C-family languages", not "C".
> Go is "a compiled, statically typed language in the tradition of Algol and C".
Note how they don't say "Go is a C".
> Likewise, Scheme is semantically very different from Common Lisp. And Racket is not considered as a Scheme, even though it is related to it. You can't copy-paste any Typed-Racket expression and run it with ChezScheme.
Yes, but in a context not centered around Common Lisp, people use "Lisp" to refer to all these languages. You can argue whether that's good or bad, but you're not able to change it.
> Take Clojure for example: the wikipedia page says that it is inspired by C++, C#, Common Lisp, Erlang, Haskell, Mathematica, ML, Prolog, Scheme, Java, Racket and Ruby. There are plenty of influences that goes into a language, why not talk about the other ones? parentheses?
Parentheses, macros, some functional programming constructs.
Look, I'm not saying the terminology is ideal. I'm saying that, in this context, "Lisp" doesn't mean what you and I want it to mean, and trying to change that will a) fail to communicate and b) fail to change the meaning of the word in this context.
Short summary: I do think on HN it's reasonable to assume "Lisp" without further qualification to refer to the lisp family. The usefulness of the lisp family idea (which afaict is having sexps and maybe something like defmacro) is questionable. Among Lisp and lisp-family practitioners outside of HN and maybe even on HN itself (it'd be interesting to see a poll result) Lisp means Common Lisp, as it has basically since Common Lisp was created, and the distinction with other lisps usually made by saying things like "Clojure is a Lisp", that article "a" being important here to say x is a member of the y family and would be nice to have in the slide title.
I agree with your argument about common usage but I'm not sure what the common usage on HN really is and what's a vocal minority using it incorrectly until it becomes common. But we've already lost several wars like that, in the wider culture ('literally' for one..) and in tech (a recent one that bugs me being 'isomorphic' JavaScript) so it's probably best to sigh in resignation and maybe think/complain about the lisp/lisp family stuff once every few years at most. ;)
> I agree with your argument about common usage but I'm not sure what the common usage on HN really is and what's a vocal minority using it incorrectly until it becomes common.
I just don't think "correctly" and "incorrectly" are words that have meaning when it comes to semantics. I care more about your goals. If your goal is to have "Lisp" mean "Common Lisp", then you can try to enforce that, but it's a strange goal to fight for, and probably not an achievable one.
Personally, my goal is to understand what people are saying and communicate my own ideas effectively. Toward that end, I just say "Common Lisp" or "CL" when I mean Common Lisp, and Lisp-family languages or Lisp-like languages when I'm talking about the larger group. And when reading, I use context clues to figure out which the person is talking about.
Certainly in the OP, it's clear that "Lisp" refers to the s-expression-y languages.
In the end it's not a very fulfilling battle even if won, to preserve the meaning of a word. I always liked the line "In the face of ambiguity, refuse the temptation to guess" as a guide to be more explicit and ask for clarification in general communication.
An article that would title "Lisp beyond Clojure" would indeed talk about the Lisp family of languages. What is a very bad in that title is that it focuses on Racket, just as if the title was: "Racket - this is how Lisp looks like beyond Clojure". And that is the main problem I have with the title. The ideal title would be IMO "What could Clojure learn from Racket".
I agree with you about actual usage, but your wish for Lisp==CL doesn't make sense either. Is LISP 1.5 "Lisp"? What about MacLisp or InterLisp or any of the other languages that both predated Common Lisp and had "lisp" in their name?
The people who create Common Lisp didn't think that is was coextensive with "Lisp", so I'm not sure why that would have become _more_ true in the last 30 years.
Lisp 1.5, Maclisp, Interlisp and CL are all Lisp. They share a common core. Common Lisp can run Lisp 1.5 code with no or little changes. The Common Lisp Object System was developed from Interlisp's LOOPS. Interlisp-D had Common Lisp and Interlisp running in one Lisp image side by side. Maclisp and Common Lisp shared complex macros like the LOOP macro in one source file at MIT.
Common Lisp even runs pre-Lisp 1.5 code. See for example:
This is frequently held up as an example of CL being more true to McCarthy's vision than Scheme. The counterargument is that code-compatibility is a poor measure of conceptually realizing McCarthy's ideals--rather Scheme's more academic approach has caused it to compromise less on McCarthy's vision. Where CL compromised for pragmatic reasons, Scheme has kept more purer abstractions, even improving on McCarthy's original Lisp. In this argument, Scheme results from a deeper understanding of of an idealized Lisp, whereas CL is a pragmatic compromise that allows Lisp to be used for industrial applications.
Personally, I don't take a side in this debate, because I don't care.
> realizing McCarthy's ideals--rather Scheme's more academic approach has caused it to compromise less on McCarthy's vision.
What were those 'ideals'? What was that vision?
> even improving on McCarthy's original Lisp
Common Lisp improved the original Lisp, too. It vastly expanded into the areas which were interesting for McCarthy: AI programming. Common Lisp was the base for thousands of research & development projects. That was McCarthy's vision: a tool for AI research.
>In this argument, Scheme results from a deeper understanding of of an idealized Lisp
No, Scheme went away from the idealized Lisp. -> R6RS.
> Personally, I don't take a side in this debate, because I don't care.
> That was McCarthy's vision: a tool for AI research.
You don't know that.
> No, Scheme went away from the idealized Lisp. -> R6RS.
Neat! I'm glad we cleared that up.
EDIT: Okay, maybe "You don't know that" is a bit strongly-worded; there's no doubt that that was part of McCarthy's vision, but there's a great more to Lisp than that, and notably, Scheme is also a pretty good tool for AI research. The real fundamental point I'm making is that the "Common Lisp is One True Lisp" vs "Scheme is One True Lisp" vs "There Are Many True Lisps" is based on unclear goals that nobody really knows. McCarthy is dead and it's questionable whether he was the sole proprietor of the "ideal Lisp" concept anyway.
Sure we know what McCarthy developed Lisp for: as a tool for AI research. It's already mentioned in the very first paragraph of the 1960 paper on Lisp.
Sure there are several Lisp dialects and a bunch of derived languages, like Scheme.
> Sure we know what McCarthy developed Lisp for: as a tool for AI research. It's already mentioned in the very first paragraph of the 1960 paper on Lisp.
> Sure there are several Lisp dialects and a bunch of derived languages, like Scheme.
Sure, that's one thing that it was when McCarthy started developing it, but the original Lisp paper doesn't say "only" and you don't know how McCarthy's intentions developed as the language developed.
> Sure, that's one thing that it was when McCarthy started developing it, but the original Lisp paper doesn't say "only" and you don't know how McCarthy's intentions developed as the language developed.
McCarthy later did not care too much about Lisp development and direction himself, since he was working on core AI topics then.
But the field of AI caused massive investment into Lisp during the 70s and 80s, until it died out in the early 90s. We are talking about something like 2 billion USD.
Ugh, when you say "Lisp" you're talking about "Common Lisp"?
AI industry has invested into a lot of languages, including Scheme, but also including stuff like C++/Java/Python/Ocaml. Trivially Google has invested more in Python AI than $2 billion, and I wouldn't be surprised if Jane Street has invested more than that in OCaml AI. So I'm not really sure what you're trying to prove here.
There isn't really a C family maybe a not-quite c family that includes c++/java/c# languages(but not c). C isn't very statically typed. C++/java/c# are object oriented (or sort of for c++) with generics/statics/inheritance, a few functional features, limited type inference. Similar looking syntax.
Rust syntax isn't really that close to c, I think it's close to ml.
> C is a language, not a family of languages that includes Rust and Go.
But Rust and Go are constantly compared to C. We always talk about C-like languages. Maybe I should have said "Algol" instead, but there is a family of languages rooted at "C", and we don't call it the C family.
Go is "a compiled, statically typed language in the tradition of Algol and C". "The syntax of Rust is similar to C and C++", but "Rust is semantically very different from C and C++.[citation needed]" (wikipedia).
Likewise, Scheme is semantically very different from Common Lisp. And Racket is not considered as a Scheme, even though it is related to it. You can't copy-paste any Typed-Racket expression and run it with ChezScheme.
So, yes, they all belong to the same proto-language family, but constantly referring to them as a unique family is doing a disservice to each of them.
Take Clojure for example: the wikipedia page says that it is inspired by C++, C#, Common Lisp, Erlang, Haskell, Mathematica, ML, Prolog, Scheme, Java, Racket and Ruby. There are plenty of influences that goes into a language, why not talk about the other ones? parentheses?