4 ms·
Just a nit-pick: clojure.java-time wraps Java's own _immutable_ java.time.* classes and it really doesn't provide much value add. I initially thought it did and
by seancorfield 4y ago
Just a nit-pick: clojure.java-time wraps Java's own _immutable_ java.time.* classes and it really doesn't provide much value add. I initially thought it did and introduced it at work but we're taking it out of a lot of our code now and using plain interop -- it's only slightly more verbose, it's already mostly "functional" in style, and it gives us more precise control over conversions between different types of date/time values.
Your main point about interop as a barrier to non-Java people is reasonable -- although if you learn a hosted language, you're going to have to learn stuff about the ecosystem on which it is hosted (so, not Java itself, but some of the JVM stuff and the docs for any libraries you interop with). And this is true of the JS ecosystem supporting ClojureScript (and the .NET ecosystem supporting ClojureCLR).
- eduction 4y agoThanks, I’ll check out the raw java-time next time I have a minute. You’re right about needing to learn some of the host in a hosted language. I’ve enjoyed for example Jsoup and I use some of the Math stuff inline with no issue. Even with the java time wrapper I’ve dropped down to the original to do certain things involving locales. I definitely knew going in to Clojure I’d need to pick up some Java. Where I really like wrappers is where the underlying java API is not great in some way. (Which now that I’ve seen the original puredanger quote seems to be what he’s saying.)
- didibus 4y ago> although if you learn a hosted language, you're going to have to learn stuff about the ecosystem on which it is hosted I thought this at first, but then I thought if you take Python, which is hosted on the OS directly through CPython, so we can say Python is hosted on Windows or Linux. Well it turns out, most people never need to interop directly with Windows or Linux APIs or any other C interop. Python seems to have a different mindset here, where most of its value proposition are providing wrappers over C/Windows/Linux/Mac APIs. Why does so much effort get put in maintaining all these wrappers in Python? Is it just attitude? Is it that those APIs are much worse then Java's enough that even C programmers using Python want to wrap them over using them directly?
- schmudde 4y agoThis is the most illustrative analogy. I suppose the answer is a little bit of both. Python numeric performance is a really interesting case. Those folks would certainly drop down to C. But my casual observation is that they would build the bridge when they came back above water. A lot of work went into this because Python performance has historically been quite bad for a Data Science/ML language. Part of this is the size of the community. But what is we also consider the Common Lisp community? Common Lisp is incredibly performant. A lot of work went into the underlying C libraries. Perhaps most of that was when the community was more vibrant. But still, a casual observation is that CL folk live in CL.