5 ms·

I read that answer, I didn't find it helpful on two points. 1. There's this really nice analogy about German and English languages, but it doesn't have any spe

I read that answer, I didn't find it helpful on two points. 1. There's this really nice analogy about German and English languages, but it doesn't have any specifics. In particular, the crux of his entire argument is in this statement > The two languages and their attendant communities have drifted so far apart that there is nothing of value in their intersection. Which he simply states as fact without any sort of follow up or justification. And I disagree. Consider this Common Lisp snippet from Wikipedia computing the answer to the birthday paradox: (defconstant +year-size+ 365) (defun birthday-paradox (probability number-of-people) (let ((new-probability (* (/ (- +year-size+ number-of-people) +year-size+) probability))) (if (< new-probability 0.5) (1+ number-of-people) (birthday-paradox new-probability (1+ number-of- people))))) Literally replace "defconstant" with "define" and "defun birthday-paradox (probability number-of-people)" with "define (birthday-paradox probability number-of-people)" and that's valid Scheme. I'll readily admit they are two different languages, but pretending they are as different as C and Python or something is absurd. 2. Even if you convince me these two languages are so different, there's nothing here to convince me Common Lisp deserves the title of the "real Lisp" or "true Lisp". Scheme can also run LISP code from 1960 with a very small driver.

Jach 10y ago
Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods? Maybe Racket (or Chicken or Chez or Guile or...) has all of these things, Racket is pretty awesome, but those things aren't standardized, whereas I can get those things in Lisp regardless of if I use SBCL/Clozure/clisp/etc. Maybe it's closer to the difference between C (with a bunch of different compiler extensions) and C++ than C and Python, but it's a pretty big difference. Ultimately I think the claim of Common Lisp being the "true Lisp" is simply that deciding such a thing was the whole point of Common Lisp. Without a standard, you're left with someone writing http://wiki.call-cc.org/eggref/4/multi-methods#examples http://wiki.call-cc.org/eggref/4/multi-methods#examples (or http://wiki.call-cc.org/eggref/4/fast-generic http://wiki.call-cc.org/eggref/4/fast-generic) and someone else writing https://docs.racket-lang.org/multimethod/index.html https://docs.racket-lang.org/multimethod/index.html and neither being able to share code with each other. Most code isn't as trivial as the birthday paradox. Would you want to try writing a (R6RS) Scheme driver for that 1960 code and see how straightforward it is? Where do you slot https://en.wikipedia.org/wiki/Dylan_(programming_language) https://en.wikipedia.org/wiki/Dylan_(programming_language) ? Should it be in the running for "the true Lisp"? If not why not?
- Volt 10y ago
  >Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods? Does Lisp from 1960 have these things? Then I guess it isn't really Lisp?
  - openasocket 9y ago
    He was just giving those as examples of ways in which Scheme and Common Lisp differ. Which is a fair point. Of course it does raise the question: are those features essential attributes of the Platonic ideal that is True Lisp, or simply nice addons Common Lisp provides?
    - Volt 9y ago
      Yeah, that's what I was getting at.
  - Jach 9y ago
    How I see it, Lisp 1.5 was Lisp, but as time went on and many 'versions' of Lisp for different systems with different capabilities came into being, there was no longer really a singular Lisp. Then there was a great unification that spit out Common Lisp, and that became Lisp. So if Lisp 1.5 was released today as something new, it wouldn't be Lisp, but merely another Lisp-like. It's too different. No one today thinks that if you drop "Lisp" in a conversation you really mean Lisp 1.5. (Maybe if you write it as LISP...) It's either going to mean Common Lisp, or maybe a reference to the vague Lisp Family. I don't think Lisp will ever be synonymous with "Scheme". Maybe you'd appreciate some Lisp history, to also answer your question about "what other dialect[s]"? http://www.paulgraham.com/thist.html http://www.paulgraham.com/thist.html http://lispm.de/30ycltl http://lispm.de/30ycltl
    - Volt 9y ago
      I do know some of the history. I was just asking those questions as a challenge. Regarding the question of the other dialect, the parent used the term as a way of distancing Scheme from what I assume is the one true Lisp: Common Lisp. But the point the passage they had an issue with noted two dialects. The other, of course, being that one true Lisp. The way I see it, the things that make Lisp "Lisp" are not exclusive to either one. One might say that the intersecting characteristics aren't interesting, but these characteristics are what Lisp is truly about. SML and Caml are both ML. Haskell 98 and Glasgow Haskell are both Haskell. Dyalog APL and APL2 are both APL. And so on.
lispm 9y ago
> Even if you convince me these two languages are so different, there's nothing here to convince me Common Lisp deserves the title of the "real Lisp" or "true Lisp" It's the lineage of Lisps where Common Lisp is in, which is Lisp: Lisp I, Lisp 1.5, Standard Lisp, Interlisp, Maclisp, New Implementation of Lisp, ZetaLisp, Spice Lisp, Common Lisp, Emacs Lisp, ISLisp, ... Those are all compatible to some extent and share a common core. Code moved a lot along these dialects. Macsyma had been written in Maclisp, moved to Zetalisp, then to Common Lisp. Reduce was written in Standard Lisp and then was ported to Common Lisp (without adoption). Hemlock was written in Spice Lisp and moved to Common Lisp. LOOPS was written in Interlisp and then moved to Zetalisp and later Common Lisp. CLOS was written in Common Lisp and was moved to Emacs Lisp and ISLisp. Even much of Common Lisp was moved to Emacs Lisp. ISLisp can be implemented as a package in Common Lisp relatively easily (Kent Pitman did this to check that ISLisp is compatible and has nothing which is not 'easily' implementable). It was also usual that some Lisp implementations ran multiple Lisp dialects side by side, sharing everything: data, memory, I/O, ... For example Interlisp-D had a Common Lisp implementation side-by-side with Interlisp. The Symbolics Lisp Machine ran Zetalisp and four variants of Common Lisp side-by-side. Then there are a lot of derived languages which either have different syntax, different semantics, different data structures, etc. Examples are Logo, MDL, Scheme, Racket, Dylan, ML, Clojure, Javascript and a bunch of other languages. Scheme initially shared some code with Lisp. Dylan tried it with a Lisp transpiler, ML initially was written in Lisp, ... > Scheme can also run LISP code from 1960 with a very small driver. The old Scheme is relatively near the Lisp mainstream, the newer Scheme less and less. Twenty years ago there was some code sharing between Lisp and Scheme, now almost none. For me there are two definitions of Lisp: * the main line compatible and sharing Lisps * the general abstract family of Lisp which share an undefine subset of a set of features: lists, s-expressions, lambdas, parentheses, ... But you can find lots of languages in the larger Lisp family which have only a rough subset of this, like Javascript or Logo.

Jach 10y ago

Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods? Maybe Racket (or Chicken or Chez or Guile or...) has all of these things, Racket is pretty awesome, but those things aren't standardized, whereas I can get those things in Lisp regardless of if I use SBCL/Clozure/clisp/etc. Maybe it's closer to the difference between C (with a bunch of different compiler extensions) and C++ than C and Python, but it's a pretty big difference. Ultimately I think the claim of Common Lisp being the "true Lisp" is simply that deciding such a thing was the whole point of Common Lisp. Without a standard, you're left with someone writing http://wiki.call-cc.org/eggref/4/multi-methods#examples http://wiki.call-cc.org/eggref/4/multi-methods#examples (or http://wiki.call-cc.org/eggref/4/fast-generic http://wiki.call-cc.org/eggref/4/fast-generic) and someone else writing https://docs.racket-lang.org/multimethod/index.html https://docs.racket-lang.org/multimethod/index.html and neither being able to share code with each other. Most code isn't as trivial as the birthday paradox. Would you want to try writing a (R6RS) Scheme driver for that 1960 code and see how straightforward it is? Where do you slot https://en.wikipedia.org/wiki/Dylan_(programming_language) https://en.wikipedia.org/wiki/Dylan_(programming_language) ? Should it be in the running for "the true Lisp"? If not why not?

Volt 10y ago
>Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods? Does Lisp from 1960 have these things? Then I guess it isn't really Lisp?
- openasocket 9y ago
  He was just giving those as examples of ways in which Scheme and Common Lisp differ. Which is a fair point. Of course it does raise the question: are those features essential attributes of the Platonic ideal that is True Lisp, or simply nice addons Common Lisp provides?
  - Volt 9y ago
    Yeah, that's what I was getting at.
- Jach 9y ago
  How I see it, Lisp 1.5 was Lisp, but as time went on and many 'versions' of Lisp for different systems with different capabilities came into being, there was no longer really a singular Lisp. Then there was a great unification that spit out Common Lisp, and that became Lisp. So if Lisp 1.5 was released today as something new, it wouldn't be Lisp, but merely another Lisp-like. It's too different. No one today thinks that if you drop "Lisp" in a conversation you really mean Lisp 1.5. (Maybe if you write it as LISP...) It's either going to mean Common Lisp, or maybe a reference to the vague Lisp Family. I don't think Lisp will ever be synonymous with "Scheme". Maybe you'd appreciate some Lisp history, to also answer your question about "what other dialect[s]"? http://www.paulgraham.com/thist.html http://www.paulgraham.com/thist.html http://lispm.de/30ycltl http://lispm.de/30ycltl
  - Volt 9y ago
    I do know some of the history. I was just asking those questions as a challenge. Regarding the question of the other dialect, the parent used the term as a way of distancing Scheme from what I assume is the one true Lisp: Common Lisp. But the point the passage they had an issue with noted two dialects. The other, of course, being that one true Lisp. The way I see it, the things that make Lisp "Lisp" are not exclusive to either one. One might say that the intersecting characteristics aren't interesting, but these characteristics are what Lisp is truly about. SML and Caml are both ML. Haskell 98 and Glasgow Haskell are both Haskell. Dyalog APL and APL2 are both APL. And so on.

lispm 9y ago

> Even if you convince me these two languages are so different, there's nothing here to convince me Common Lisp deserves the title of the "real Lisp" or "true Lisp" It's the lineage of Lisps where Common Lisp is in, which is Lisp: Lisp I, Lisp 1.5, Standard Lisp, Interlisp, Maclisp, New Implementation of Lisp, ZetaLisp, Spice Lisp, Common Lisp, Emacs Lisp, ISLisp, ... Those are all compatible to some extent and share a common core. Code moved a lot along these dialects. Macsyma had been written in Maclisp, moved to Zetalisp, then to Common Lisp. Reduce was written in Standard Lisp and then was ported to Common Lisp (without adoption). Hemlock was written in Spice Lisp and moved to Common Lisp. LOOPS was written in Interlisp and then moved to Zetalisp and later Common Lisp. CLOS was written in Common Lisp and was moved to Emacs Lisp and ISLisp. Even much of Common Lisp was moved to Emacs Lisp. ISLisp can be implemented as a package in Common Lisp relatively easily (Kent Pitman did this to check that ISLisp is compatible and has nothing which is not 'easily' implementable). It was also usual that some Lisp implementations ran multiple Lisp dialects side by side, sharing everything: data, memory, I/O, ... For example Interlisp-D had a Common Lisp implementation side-by-side with Interlisp. The Symbolics Lisp Machine ran Zetalisp and four variants of Common Lisp side-by-side. Then there are a lot of derived languages which either have different syntax, different semantics, different data structures, etc. Examples are Logo, MDL, Scheme, Racket, Dylan, ML, Clojure, Javascript and a bunch of other languages. Scheme initially shared some code with Lisp. Dylan tried it with a Lisp transpiler, ML initially was written in Lisp, ... > Scheme can also run LISP code from 1960 with a very small driver. The old Scheme is relatively near the Lisp mainstream, the newer Scheme less and less. Twenty years ago there was some code sharing between Lisp and Scheme, now almost none. For me there are two definitions of Lisp: * the main line compatible and sharing Lisps * the general abstract family of Lisp which share an undefine subset of a set of features: lists, s-expressions, lambdas, parentheses, ... But you can find lots of languages in the larger Lisp family which have only a rough subset of this, like Javascript or Logo.