5 ms·
As someone who programs in Clojure--and therefore has no justification for weighing in--I _believe_ that it's a cultural or generational difference. That is, fo
by delish 8y ago
As someone who programs in Clojure--and therefore has no justification for weighing in--I _believe_ that it's a cultural or generational difference. That is, for certain programmers (working in the 1980s? 1990s?) "Lisp" (capital-L, lower-case isp) meant Common Lisp, and many agreed.
I am sure that people tediously, fruitlessly argue about it. But it's also true that for a wide swath of programmers, Lisp is Common Lisp.
I wonder if hn's lisper or lispm could weigh in...
- darkpuma 8y agoArguments about labels are always tedious and fruitless. They don't advance anybody's understanding of anything important, like the substance of the whatever those labels might apply to. Arguing about whether or not "Lisp" means "Common Lisp" doesn't advance anybody's understanding of Common Lisp.
- delish 8y agoI agree with everything you said. The argument is tedious and fruitless. My point is an empirical one: Programmers of a Certain Age were more likely to use "Lisp" than programmers of other ages.
- kazinator 8y agoThe sentence at the root of this subthread, namely "I do really wish that Guix used Lisp rather than Scheme" isn't an argument about labels.
- darkpuma 8y agoNo, but the terminology of the root was plainly coming from the camp of "Scheme isn't Lisp, Common Lisp is Lisp." The child comment was confused by that peculiar terminology, so I provided context for that terminology in a way that I hoped would head off yet another argument about labels. It was my intent to stop the argument before it began.
- deleted 8y ago[deleted]
- kazinator 8y agoThe terminology is troublesome because "Scheme" more specifically determines the language than "Lisp", so "I'd prefer to use Lisp over Scheme" or vice versa is somewhat "apples versus vegetables".
- lispm 8y ago> Arguing about whether or not "Lisp" means "Common Lisp" doesn't advance anybody's understanding of Common Lisp. But not expecting Common Lisp to behave like Scheme helps. The design for the Scheme language is simply different from Common Lisp and thus code looks and behaves differently.
- kazinator 8y agoFor a wide swath of programmers, a Lisp is something with lists made of mutable cons cells, terminated by a nil symbol which is both false and the empty list. I don't think you will encounter too many Common Lisp programmers who don't think that Emacs Lisp is a "Lisp". Scheme doesn't use "Lisp" in its name. It has its own Usenet newsgroup; Scheme programming is rarely discussed in comp.lang.lisp. Likewise it has its own subreddit; r/lisp isn't used much for discussing Scheme. "I would rather this were implemented in Scheme rather than Lisp" (or vice versa) is a perfectly understandable statement and sentiment that is not simply about semantic labels.
- mbrock 8y agoAnd now Racket, which used to be a Scheme, doesn't call itself a Scheme anymore. In fact it describes itself on its web site as "The best of Scheme and Lisp."
- kazinator 8y agoThat is correct; you can't be Scheme if you just have the best of it, and not the rest of it. E.g. Racket doesn't have set-car! and set-cdr! so RnRS-conforming Scheme programs which rely on these won't work.
- mbrock 8y agoOn the other hand some weirdos try to claim that Python is “a Lisp”...
- soegaard 8y agoRacket does support mutable pairs. http://docs.racket-lang.org/reference/mpairs.html?q=mcons#%28part._.Mutable_.Pair_.Constructors_and_.Selectors%29 http://docs.racket-lang.org/reference/mpairs.html?q=mcons#%2...
- kazinator 8y agoThat's nice, but in Scheme, all pairs constructed by any code anywhere are mutable, and structure made out of mutable pairs can be passed into any library function. An object notation like (a b c) read from a stream gives you a mutable object. It's a significant language difference that can't be papered over with a data type and handful of functions.