4 ms·

You're bunching Clojure in with several languages that have strayed far further from Lisp. Clojure was designed specifically with the intent of being a dialect

by 59nadir 11y ago

You're bunching Clojure in with several languages that have strayed far further from Lisp. Clojure was designed specifically with the intent of being a dialect of Lisp, which means it's explicitly not in its own language family or in any other language family than Lisp.

lispm 11y ago
> Clojure was designed specifically with the intent of being a dialect of Lisp The result of that design is that Clojure shares literally zero lines of code with other Lisps: Autolisp, ISLisp, Emacs Lisp, Standard Lisp, Common Lisp. Many basic concepts are absent, renamed or redesigned ('Atom', 'Linked List', ...). Clojure is fully incompatible to any other language with Lisp in its name. Programs have to be re-architectured, because the concepts are different: no TCO, but 'functional', different approach about side effects (-> avoid), lazy persistent datastructure at its core, different idea of OOP (-> avoid), Lisp infrastructure (-> avoid), ... There is no software I know of, which is shared. The number of tools shared is 'one': GNU Emacs. It's a different community with different goals, different software, different applications, different libraries. Just think of it: zero lines of code is shared. My problem with that broader idea of 'Lisp': it is fully vague and it has no practical implications. Sometimes it's only a marketing slogan. It has the same vague meaning like 'object-oriented' or 'Functional'. There is no consensus what OOP in a broad sense means and how it should be defined. 'Lisp' is just as useless. It does not mean that Clojure is useless or worse than Lisp. Totally not. Clojure has new ideas on data structures put to work and enabled some very productive people enjoying their tools. They are doing wonderful stuff.
- yxhuvud 11y ago
  Would you consider Scheme a lisp? It is after all also not sharing any code with the above mentioned (by necessity, since it use define instead of defun for declaring functions).
  - agumonkey 11y ago
    Same about racket. Is it a scheme, even a lisp ? I understand a bit more why they changed their name from PLT scheme to racket now.
- 59nadir 11y ago
  > The result of that design is that Clojure shares literally zero lines of code with other Lisps: Autolisp, ISLisp, Emacs Lisp, Standard Lisp, Common Lisp. Many basic concepts are absent, renamed or redesigned ('Atom', 'Linked List', ...). Clojure is fully incompatible to any other language with Lisp in its name. > Programs have to be re-architectured, because the concepts are different: "Re-architectured" can be read in a multitude of ways. Changing a few datatypes because Clojure prefers vectors instead of lists, etc., feels like it falls well below the bar for "re-architectured". > no TCO, but 'functional' This would hold weight if CL mandated TCO, but it doesn't. With this in mind, I'd like to examine a few of your points from a different angle: Racket: - Basic concepts are the same, (atom, linked lists, '...') - Restructuring not really needed (up for debate, depends entirely on your prefered initial design choices in either language. Racket isn't that opinionated.) - Tail call optimization required as per Scheme standard, so is present. Note that this is not actually something Lisp mandates. - Doesn't 'care' about side effects, community is pragmatic and will generally advise you to do whatever is practical - Has an object oriented sub-language with message passing and so on There are a lot of points here that, according to you, makes Racket essentially a Lisp, even your non-point about TCO. I'm curious to know what you feel about people saying Scheme is a Lisp, considering the above. The whole debate of "Is X (a) Lisp?" reminds me of nationality debates that essentially boil down to some people saying blood is more important than culture. You seem to be taking both sides, however; arguing culture and blood (source code). You cherry pick the cultural differences like most people standing on one side of the nationality debate would and argue that just those specific differences are the most important. That's the thing, though; Swedish people could argue however much they want that they're very different from Norwegian people. To the rest of the world, though, they're essentially the same. Especially when you start comparing them to people from Peru, Venezuela, South Africa, and so on. When you're in the bubble the very small differences are much bigger to you, but if you zoom out to get some perspective these differences are much smaller than the commonalities.
  - lispm 11y ago
    Shriram Krishnamurthi says about this topic: > Racket is Racket. It's its own language.
- treerex 11y ago
  > no TCO Neither does Emacs Lisp nor ABCL. Yet they are Lisps by your definition. > different approach about side effects (-> avoid) Though not precluded. You can write Clojure with side-effects, but to do so you need to be explicit about it. > different idea of OOP (-> avoid) Which says nothing about the language or its Lisp-nature. Clojure has generic dispatch with multimethods, supporting runtime polymorphism. As you say later, "OOP" is meaningless since it's definition is vague, so using this as a reason for Clojure to not be a Lisp is odd. > Just think of it: zero lines of code is shared. Are saying that a lisp is only a 'Lisp' if you can freely share code between them? Without modification? If the names used for functions aren't the same, then that disqualifies it from being a Lisp? Your position seems to be that unless the lisp is a direct descendant of Lisp 1.5 then it cannot be called a Lisp. In addition to Clojure, this disqualifies Scheme (and its dialects.) Different Lisps (by your definition) take different approaches to things like namespace separation (Lisp-1 vs. Lisp-2) and scope (dynamic vs. lexical). These differences can be subtle and lead to hard to find bugs when sharing code. > My problem with that broader idea of 'Lisp': it is fully vague and it has no practical implications. Yet you have put a stake in the ground and defined the broad idea of 'Lisp' as an entity that shares its roots with the ideas in MacLisp.

by 59nadir 11y ago

lispm 11y ago

> Clojure was designed specifically with the intent of being a dialect of Lisp The result of that design is that Clojure shares literally zero lines of code with other Lisps: Autolisp, ISLisp, Emacs Lisp, Standard Lisp, Common Lisp. Many basic concepts are absent, renamed or redesigned ('Atom', 'Linked List', ...). Clojure is fully incompatible to any other language with Lisp in its name. Programs have to be re-architectured, because the concepts are different: no TCO, but 'functional', different approach about side effects (-> avoid), lazy persistent datastructure at its core, different idea of OOP (-> avoid), Lisp infrastructure (-> avoid), ... There is no software I know of, which is shared. The number of tools shared is 'one': GNU Emacs. It's a different community with different goals, different software, different applications, different libraries. Just think of it: zero lines of code is shared. My problem with that broader idea of 'Lisp': it is fully vague and it has no practical implications. Sometimes it's only a marketing slogan. It has the same vague meaning like 'object-oriented' or 'Functional'. There is no consensus what OOP in a broad sense means and how it should be defined. 'Lisp' is just as useless. It does not mean that Clojure is useless or worse than Lisp. Totally not. Clojure has new ideas on data structures put to work and enabled some very productive people enjoying their tools. They are doing wonderful stuff.

yxhuvud 11y ago
Would you consider Scheme a lisp? It is after all also not sharing any code with the above mentioned (by necessity, since it use define instead of defun for declaring functions).
- agumonkey 11y ago
  Same about racket. Is it a scheme, even a lisp ? I understand a bit more why they changed their name from PLT scheme to racket now.
59nadir 11y ago
> The result of that design is that Clojure shares literally zero lines of code with other Lisps: Autolisp, ISLisp, Emacs Lisp, Standard Lisp, Common Lisp. Many basic concepts are absent, renamed or redesigned ('Atom', 'Linked List', ...). Clojure is fully incompatible to any other language with Lisp in its name. > Programs have to be re-architectured, because the concepts are different: "Re-architectured" can be read in a multitude of ways. Changing a few datatypes because Clojure prefers vectors instead of lists, etc., feels like it falls well below the bar for "re-architectured". > no TCO, but 'functional' This would hold weight if CL mandated TCO, but it doesn't. With this in mind, I'd like to examine a few of your points from a different angle: Racket: - Basic concepts are the same, (atom, linked lists, '...') - Restructuring not really needed (up for debate, depends entirely on your prefered initial design choices in either language. Racket isn't that opinionated.) - Tail call optimization required as per Scheme standard, so is present. Note that this is not actually something Lisp mandates. - Doesn't 'care' about side effects, community is pragmatic and will generally advise you to do whatever is practical - Has an object oriented sub-language with message passing and so on There are a lot of points here that, according to you, makes Racket essentially a Lisp, even your non-point about TCO. I'm curious to know what you feel about people saying Scheme is a Lisp, considering the above. The whole debate of "Is X (a) Lisp?" reminds me of nationality debates that essentially boil down to some people saying blood is more important than culture. You seem to be taking both sides, however; arguing culture and blood (source code). You cherry pick the cultural differences like most people standing on one side of the nationality debate would and argue that just those specific differences are the most important. That's the thing, though; Swedish people could argue however much they want that they're very different from Norwegian people. To the rest of the world, though, they're essentially the same. Especially when you start comparing them to people from Peru, Venezuela, South Africa, and so on. When you're in the bubble the very small differences are much bigger to you, but if you zoom out to get some perspective these differences are much smaller than the commonalities.
- lispm 11y ago
  Shriram Krishnamurthi says about this topic: > Racket is Racket. It's its own language.
treerex 11y ago
> no TCO Neither does Emacs Lisp nor ABCL. Yet they are Lisps by your definition. > different approach about side effects (-> avoid) Though not precluded. You can write Clojure with side-effects, but to do so you need to be explicit about it. > different idea of OOP (-> avoid) Which says nothing about the language or its Lisp-nature. Clojure has generic dispatch with multimethods, supporting runtime polymorphism. As you say later, "OOP" is meaningless since it's definition is vague, so using this as a reason for Clojure to not be a Lisp is odd. > Just think of it: zero lines of code is shared. Are saying that a lisp is only a 'Lisp' if you can freely share code between them? Without modification? If the names used for functions aren't the same, then that disqualifies it from being a Lisp? Your position seems to be that unless the lisp is a direct descendant of Lisp 1.5 then it cannot be called a Lisp. In addition to Clojure, this disqualifies Scheme (and its dialects.) Different Lisps (by your definition) take different approaches to things like namespace separation (Lisp-1 vs. Lisp-2) and scope (dynamic vs. lexical). These differences can be subtle and lead to hard to find bugs when sharing code. > My problem with that broader idea of 'Lisp': it is fully vague and it has no practical implications. Yet you have put a stake in the ground and defined the broad idea of 'Lisp' as an entity that shares its roots with the ideas in MacLisp.