7 ms·
> 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 usele
by imagist 10y ago
> 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.
- samth 10y agoI 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.
- lispm 10y agoLisp 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: https://gist.github.com/lispm/93bba58caf3d3c7aab3b https://gist.github.com/lispm/93bba58caf3d3c7aab3b That's original McCarthy code from 1960 in s-expression syntax. Runs mostly unchanged.
- imagist 10y agoThis 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.
- lispm 10y ago> 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. Yeah, sure.
- 10y ago
- Jach 10y agoI'll just leave two of my old comments here... https://news.ycombinator.com/item?id=10207199 https://news.ycombinator.com/item?id=10207199 and https://news.ycombinator.com/item?id=3423646 https://news.ycombinator.com/item?id=3423646 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. ;)
- imagist 10y ago> 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.
- junke 10y agoAn 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".