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.
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.
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.
Standards come about to address compatibiltiy problems. Languages with many independent implementations and competing mutually incompatible implementation specific extensions (like C++ and Common Lisp) have a lot more problems to solve in this department to begin with compared to languages that have one defacto market leader implementation that everyone targets to be compatible with.
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.
reply