Agreed. Clojure isn't overall a bad language, but it has annoying quirks in a lot of places, presumably because it needs to be compatible with Java. The ones that annoy me the most are (0) `nil` and `false` being different, and (1) wonky arithmetic that uses Java's numeric types under the hood, unless you explicitly ask it not to.
I agree - this is the only right answer. Like you, I'm sad to have to accept it, but it's the only way to a frustration-free (or lower-frustration) Clojure experience.
Clojure is a pragmatic language, and I think if you just reject the immense value of being on the JVM and try to treat it as something pure and unsullied then you're missing a lot of its motivation.
And by writing Clojure, you lose a lot of type safety and compile-time efficiency. Not that that's a bad thing, just pointing out that there's a trade-off that it makes in favor of a simpler language to learn and implement. There's also the matter of it being more verbose to represent certain concepts in Clojure due to lack of syntax, but that's harder to argue.
Everybody can do that stuff in Clojure too, and it does not suffer from the same thing CL does. It seems to me that it is a culture/ecosystem problem more then anything else.
Clojure is currently my favorite language, partly for the pragmatic choices it made, but these pragmatic choices will limit its continued use.
Hygienic macros often prevent one from shooting oneself into the foot, but they prevent also some truly elegant code. Having lists and vectors with a common interface is cool, but that the semantics of conj is different for both is annoying. Easy java interop is worth a lot, but it prevents call/cc.
It's probable that i will gladly use Clojure for the next 10, maybe even 20 years, but it won't be the programming language my grandchildren will ask me to shut up about.
How is it that you think Clojure has trouble doing things in a non-functional way? I'm just curious, as I work in Clojure primarily and may have a huge blind spot I'd love to clear out!
reply