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?
Differences with other Lisps
101–108 of 108 posts
Re: Differences with other Lisps
#102Earlier 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?
Re: Differences with other Lisps
#103Earlier 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
Re: Differences with other Lisps
#104Earlier 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.
Re: Differences with other Lisps
#105Earlier 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.
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
#106Earlier 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.
Re: Differences with other Lisps
#107Earlier 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 'correction' you made is an entirely different issue.
Re: Differences with other Lisps
#108Earlier 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.