3 ms·

Clojure is widely considered a lisp, but it also does not have cons cells. You are free to use your own definition of "lisp" but it is contrary to the widely ac

Clojure is widely considered a lisp, but it also does not have cons cells. You are free to use your own definition of "lisp" but it is contrary to the widely accepted use of the term.

lispm 11y ago
I don't think Clojure is a Lisp. iT's just another Lisp inspired language. Again, zero code of the past fifty+ years of Lisp runs in Clojure. iT is fully incompatible with any Lisp dialect. It shares zero lines of code. Don't believe what people tell you, think yourself. if you had a language, which uses { and }, would you call it a C, if it is 100% incompatible to any line of C written out there? For some reason some people think any random incompatible language with parentheses is a Lisp. That's because they use some completely unspecific definition of Lisp, which is based on vague features, but which has no practical consequences.
- swhipple 11y ago
  > if you had a language, which uses { and }, would you call it a C, if it is 100% incompatible to any line of C written out there? No, but nobody else would either. For Lisp and Forth dialects, people seem to accept that they are not all backwards compatible with a specific implementation or spec, but are the same family of languages. [1] Clojure's and Racket's official docs both refer to the languages as Lisp dialects (Racket) or Lisps (Clojure). Other reputable sources also consider them to be dialects of Lisp. If it doesn't meet your own prescriptive criteria for being called a Lisp, that's fine, but the parent is only being pragmatic in using the same sense that is widely used and accepted. [1] FWIW, I've always read "is a Lisp"/"Lisps" as "is a Lisp dialect"/"Lisp dialects" and think that most others do as well. Not necessarily married to implementation details or compatibility.
- amirouche 11y ago
  homoiconism is a feature of the lisp that has important consequences like tail-call optimization. Replacing the use of macros or recursive algorithms leads to terse OO equation that is not as readable as the expression of the same "algorithm"/"intent" using macros and recursion.

Clojure is widely considered a lisp, but it also does not have cons cells. You are free to use your own definition of "lisp" but it is contrary to the widely accepted use of the term.

lispm 11y ago

I don't think Clojure is a Lisp. iT's just another Lisp inspired language. Again, zero code of the past fifty+ years of Lisp runs in Clojure. iT is fully incompatible with any Lisp dialect. It shares zero lines of code. Don't believe what people tell you, think yourself. if you had a language, which uses { and }, would you call it a C, if it is 100% incompatible to any line of C written out there? For some reason some people think any random incompatible language with parentheses is a Lisp. That's because they use some completely unspecific definition of Lisp, which is based on vague features, but which has no practical consequences.

swhipple 11y ago
> if you had a language, which uses { and }, would you call it a C, if it is 100% incompatible to any line of C written out there? No, but nobody else would either. For Lisp and Forth dialects, people seem to accept that they are not all backwards compatible with a specific implementation or spec, but are the same family of languages. [1] Clojure's and Racket's official docs both refer to the languages as Lisp dialects (Racket) or Lisps (Clojure). Other reputable sources also consider them to be dialects of Lisp. If it doesn't meet your own prescriptive criteria for being called a Lisp, that's fine, but the parent is only being pragmatic in using the same sense that is widely used and accepted. [1] FWIW, I've always read "is a Lisp"/"Lisps" as "is a Lisp dialect"/"Lisp dialects" and think that most others do as well. Not necessarily married to implementation details or compatibility.
amirouche 11y ago
homoiconism is a feature of the lisp that has important consequences like tail-call optimization. Replacing the use of macros or recursive algorithms leads to terse OO equation that is not as readable as the expression of the same "algorithm"/"intent" using macros and recursion.