Live data from Hacker News

Differences with other Lisps

clojure.org

101–108 of 108 posts

Re: Differences with other Lisps

#101
post #67

Earlier quoted context omitted.

The commercial Common Lisp I use, also has large amounts of extensions to CL. Including a function to split sequences/strings, parallel and concurrent extensions, ... ;-) It's actually the same commercial Common Lisp which Rich Hickey used years ago to write his first Lisp programs and where he developed his first ideas for Clojure.

Are you working under an NDA or something? Are you being threatened? Blink three times if you need help. Seriously, is there a reason you have to hint about what Lisp you use?

Is there a reason you can't ask politely?

Re: Differences with other Lisps

#102

Earlier quoted context omitted.

Are you working under an NDA or something? Are you being threatened? Blink three times if you need help. Seriously, is there a reason you have to hint about what Lisp you use?

Is there a reason you can't ask politely?

Because I thought it was funny, and I'm pretty sure lispm has enough sense of humor not to need a valiant protector today.

Re: Differences with other Lisps

#103
post #100

Earlier quoted context omitted.

> Like lots of languages. Incl. Lisp itself. Sure, I'm just highlighting that your statement about Clojure is correct when it comes to compatibility against other languages while being incorrect if you consider it within the Clojure ecosystem itself.

You might want to tell the maintainers about their error: > Clojure is a Lisp not constrained by backwards compatibility https://clojure.org/about/rationale

No need, the maintainers of Clojure.core knows about it, propagates the idea and most people in the community follows it as well.

Re: Differences with other Lisps

#104
post #100

Earlier quoted context omitted.

You might want to tell the maintainers about their error: > Clojure is a Lisp not constrained by backwards compatibility https://clojure.org/about/rationale

No need, the maintainers of Clojure.core knows about it, propagates the idea and most people in the community follows it as well.

Right, that it is compatible to itself does not sound particular noteworthy. Lots of language eco-systems have that. That's also why many languages (like C, C++, JavaScript, Java, Ada, Common Lisp, ISLISP and Scheme) have actual language standards with, where there is a high focus on protecting investments.

Re: Differences with other Lisps

#105
post #104

Earlier quoted context omitted.

No need, the maintainers of Clojure.core knows about it, propagates the idea and most people in the community follows it as well.

Right, that it is compatible to itself does not sound particular noteworthy. Lots of language eco-systems have that. That's also why many languages (like C, C++, JavaScript, Java, Ada, Common Lisp, ISLISP and Scheme) have actual language standards with, where there is a high focus on protecting investments.

I'm not submitting "Clojure and the ecosystem focuses on being backwards compatibility" as a new HN story. I'm simply adding additional information to your "Clojure was designed with no backwar(d/t)s compatibility" statement which could be read as "Clojure core/libraries break their own API interface all the time" (like in the JS/NPM ecosystem) which is simply not true.

Just to be clear, I'm not saying this is unique in Clojure, simply making sure that others who read your comment don't read it the wrong way as it was a bit ambiguous.

Re: Differences with other Lisps

#106
post #104

Earlier quoted context omitted.

No need, the maintainers of Clojure.core knows about it, propagates the idea and most people in the community follows it as well.

Right, that it is compatible to itself does not sound particular noteworthy. Lots of language eco-systems have that. That's also why many languages (like C, C++, JavaScript, Java, Ada, Common Lisp, ISLISP and Scheme) have actual language standards with, where there is a high focus on protecting investments.

Standards come about to address compatibility problems, and standards bodies are committees where reps of divergent implementations settle on compromises (or sufficiently vague langugage) to get some compatibility. Python, Clojure, C# etc don't need standards since there haven't been problems wtith competing incompatible variants of the languages out there.

Re: Differences with other Lisps

#107
post #104

Earlier quoted context omitted.

Right, that it is compatible to itself does not sound particular noteworthy. Lots of language eco-systems have that. That's also why many languages (like C, C++, JavaScript, Java, Ada, Common Lisp, ISLISP and Scheme) have actual language standards with, where there is a high focus on protecting investments.

I'm not submitting "Clojure and the ecosystem focuses on being backwards compatibility" as a new HN story. I'm simply adding additional information to your "Clojure was designed with no backwar(d/t)s compatibility" statement which could be read as "Clojure core/libraries break their own API interface all the time" (like in the JS/NPM ecosystem) which is simply not true. Just to be clear, I'm not saying this is unique…

The context is very clear the comparison to other languages, when it is clearly the fact that Clojure was designed with no backwards compatibility to these mentioned languages. It was not a matter of a list of things on that page, but the break with the prior languages was much more radical.

The 'correction' you made is an entirely different issue.

Re: Differences with other Lisps

#108
post #76
post #68

Earlier quoted context omitted.

Is this surprising? I don't see an ecosystem of languages targeting the Go runtime, in contrast to the JVM, Javascript, Erlang, MS CLR... I don't think this is necessarily a matter of popularity or maturity. I don't know of languages that compile to Python bytecode, either. In Python's case I suspect the VM is so optimized for Python that it makes an inflexible target for other languages: I don't know enough about th…

> Is this surprising? I don't see an ecosystem of languages targeting the Go runtime, in contrast to the JVM, Javascript, Erlang, MS CLR... I think I'm surprised in general that no language targets the Go runtime. A ML built on Go could probably be popular, lots of people would like features from it. Not exactly bytecode but Hy https://github.com/hylang/hy is a dialect of Lisp that compiles to Python.

Hy actually compiles directly to Python AST, not to Python. For a Lisp that compiles to Python, see Hissp: https://github.com/gilch/hissp
Post reply on HN