4 ms·

> Clojure doesn't have a spec at all (it has documentation for the single implementation; it seems to have another implementation which is even more a toy since

by m45t3r 6y ago

> Clojure doesn't have a spec at all (it has documentation for the single implementation; it seems to have another implementation which is even more a toy since no real Clojure programs can run on it, because JVM is part of Clojure, really...) It is true that Clojure doesn't have a spec, but it is very stable. I saw some very minor breaking changes in Clojure, and most code just works after a update (including very big projects). Clojure is very conservative in general, and this is something that Rich says as a explicit design goal. BTW, are you referring to ClojureScript? Because ClojureScript is far from a toy language, it works well and we use in production. Sure it have some warts, but they're mostly workable and while I am not a fan, I am not a fan of frontend in general so this is probably part of the problem.

bluefox 6y ago
I was thinking about ClojureCLR. While my argument could be applied to ClojureScript, I did not think it was fair because ClojureScript calls itself a (proper) subset of Clojure, which is fine and no one expects it to run actual Clojure programs. Again, I apologize for undue harshness.
- didibus 6y ago
  Lots of Clojure code is portable between Clojure, Clojure CLR and ClojureScript. The differences honestly are often pretty similar to what some CL implementations differ in: host interop and multi-threading/concurrency. The biggest difference is that Clojure standard library doesn't wrap all host APIs, so there's a bigger reliance on direct host interop. That's the main thing. And because the hosts themselves don't all share APIs, the interop specific code needs to be written specifically to the host. It's a similar story for multi-threading and concurrency, some hosts don't support it at all, or support a very different version like Actors only, so in those cases the Clojure features related to them are dropped or altered to match the host. You can still provide multi-host libraries, by making use of reader conditionals you can have the code fork at the points where it needs to be specialized for each host. That in turn can be used portably afterwards on whatever hosts the library would have supported.

by m45t3r 6y ago

bluefox 6y ago

I was thinking about ClojureCLR. While my argument could be applied to ClojureScript, I did not think it was fair because ClojureScript calls itself a (proper) subset of Clojure, which is fine and no one expects it to run actual Clojure programs. Again, I apologize for undue harshness.

didibus 6y ago
Lots of Clojure code is portable between Clojure, Clojure CLR and ClojureScript. The differences honestly are often pretty similar to what some CL implementations differ in: host interop and multi-threading/concurrency. The biggest difference is that Clojure standard library doesn't wrap all host APIs, so there's a bigger reliance on direct host interop. That's the main thing. And because the hosts themselves don't all share APIs, the interop specific code needs to be written specifically to the host. It's a similar story for multi-threading and concurrency, some hosts don't support it at all, or support a very different version like Actors only, so in those cases the Clojure features related to them are dropped or altered to match the host. You can still provide multi-host libraries, by making use of reader conditionals you can have the code fork at the points where it needs to be specialized for each host. That in turn can be used portably afterwards on whatever hosts the library would have supported.