4 ms·

That's surprising. I listed the interop caveats here because sometimes it feels like a bandage intended to bridge some gap until Clojure matures. But if Alex s

That's surprising. I listed the interop caveats here because sometimes it feels like a bandage intended to bridge some gap until Clojure matures. But if Alex said that, then maybe it's not. ¯\_(ツ)_/¯

mark_l_watson 4y ago
Janet, I hope I didn’t misquote him. I save his tweet, and I am going to look for it.
- mark_l_watson 4y ago
  “Idiomatic Clojure code calls Java libraries directly and doesn’t try to wrap everything under the sun to look like Lisp… Where Java isn’t broken, Clojure doesn’t fix it.”
  - janetacarr 4y ago
    Thanks for the quote Mark, it's an interesting perspective.
  - fmakunbound 4y ago
    Perhaps that stance has changed over time. In Clojure, there's the clojure.string namespace just functions wrapping java.lang.String methods https://clojuredocs.org/clojure.string https://clojuredocs.org/clojure.string
    - moomin 4y ago
      I think the problem is that if you want to write code portable between clj and cljs, you’re gonna need a lightweight abstraction. With that said, I’m still not sure how exactly the maintainers feel about portable code, having written a portable http library.
    - casion 4y ago
      This is much more than "just wrapping". It allows strings to be used more readily with existing Clojure abstractions and/or allows idiomatic use without the need for being on guard to avoid reflection. Notably, Alex didn't write this library and only has a minor contribution to it.
    - didibus 4y ago
      There's two cases where you'll see pragmatic wrapping: 1. Higher order usage. When functions would really benefit from being used in a higher order way, passed around as values, you'll see some of the Java methods wrapped so they can more easily be used as such, since you can't use Java methods in a higher order way. This would count as "can do it better", and it's the case for clojure.string. 2. For portability with Clojurescript. This is a more recent thing, but as Clojurescript usage grows, and code reuse between backed and frontend more common, there are certain basic methods Java interop was totally fine with that now benefits from being wrapped. This is the case for clojure.math.
  - fat_cantor 4y ago
    I can confirm that a major impediment to learning Clojure is understanding where Java is and isn't broken.
    - puredanger 4y ago
      I think this is insightful and probably an unconscious bias of the core team (who have all used Java for decades) and have a good sense of that.
huahaiy 4y ago
Clojure is intended as a hosted language and embracing the host is the philosophy, so interop with the host is never a bandage. Again, I am curious where you get all these impressions that are contrary to most people in the community take for granted, such as: * Clojurians prefer libraries over framework, but you said we spent too much effort in developing "big web framework". * Clojure is intended to be a hosted language, so seamless interop with the host is the norm, but you thought interop is a bandage until Clojure matures. It's very interesting.
didibus 4y ago
Really it's not. The interop is a conscious decision core to the language rationale. https://clojure.org/about/rationale https://clojure.org/about/rationale > Customers and stakeholders have substantial investments in, and are comfortable with the performance, security and stability of, industry-standard platforms like the JVM. While Java developers may envy the succinctness, flexibility and productivity of dynamic languages, they have concerns about running on customer-approved infrastructure, access to their existing code base and libraries, and performance > symbiotic with an established Platform > VMs, not OSes, are the platforms of the future, providing: [...] * Libraries * Abstract away OSes * Huge set of facilities * Built-in and 3rd-party https://clojure.org/about/jvm_hosted https://clojure.org/about/jvm_hosted > Clojure is designed to be a hosted language, sharing the JVM type system, GC, threads etc. > Clojure is a great Java library consumer Where Clojure had nothing to bring, nothing was implemented, because interop is considered just as good, that's why there's not a lot of IO functions in core, and why math was missing for a long time.
- eduction 4y ago
  A good wrapper (like the Clojure version of java-time) can be a real lifesaver for those of us without Java backgrounds who don’t like having to learn deep and often baroque Java apis. I also use a pretty half baked wrapper someone wrote because I just about lost my mind trying to make sense of the class hierarchy it was wrapping. I think for people like Rich and Alex wrappers may look pointless because they already have invested in learning many of these APIs, know the patterns already, etc. For people like me from different language backgrounds they keep me from having to learn APIs with mutable state and deep class hierarchies and to me that’s a big win. (I rewrote this whole comment to hopefully be more concise.)
  - 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).

mark_l_watson 4y ago

Janet, I hope I didn’t misquote him. I save his tweet, and I am going to look for it.

mark_l_watson 4y ago
“Idiomatic Clojure code calls Java libraries directly and doesn’t try to wrap everything under the sun to look like Lisp… Where Java isn’t broken, Clojure doesn’t fix it.”
- janetacarr 4y ago
  Thanks for the quote Mark, it's an interesting perspective.
- fmakunbound 4y ago
  Perhaps that stance has changed over time. In Clojure, there's the clojure.string namespace just functions wrapping java.lang.String methods https://clojuredocs.org/clojure.string https://clojuredocs.org/clojure.string
  - moomin 4y ago
    I think the problem is that if you want to write code portable between clj and cljs, you’re gonna need a lightweight abstraction. With that said, I’m still not sure how exactly the maintainers feel about portable code, having written a portable http library.
  - casion 4y ago
    This is much more than "just wrapping". It allows strings to be used more readily with existing Clojure abstractions and/or allows idiomatic use without the need for being on guard to avoid reflection. Notably, Alex didn't write this library and only has a minor contribution to it.
  - didibus 4y ago
    There's two cases where you'll see pragmatic wrapping: 1. Higher order usage. When functions would really benefit from being used in a higher order way, passed around as values, you'll see some of the Java methods wrapped so they can more easily be used as such, since you can't use Java methods in a higher order way. This would count as "can do it better", and it's the case for clojure.string. 2. For portability with Clojurescript. This is a more recent thing, but as Clojurescript usage grows, and code reuse between backed and frontend more common, there are certain basic methods Java interop was totally fine with that now benefits from being wrapped. This is the case for clojure.math.
- fat_cantor 4y ago
  I can confirm that a major impediment to learning Clojure is understanding where Java is and isn't broken.
  - puredanger 4y ago
    I think this is insightful and probably an unconscious bias of the core team (who have all used Java for decades) and have a good sense of that.

huahaiy 4y ago

Clojure is intended as a hosted language and embracing the host is the philosophy, so interop with the host is never a bandage. Again, I am curious where you get all these impressions that are contrary to most people in the community take for granted, such as: * Clojurians prefer libraries over framework, but you said we spent too much effort in developing "big web framework". * Clojure is intended to be a hosted language, so seamless interop with the host is the norm, but you thought interop is a bandage until Clojure matures. It's very interesting.

didibus 4y ago

Really it's not. The interop is a conscious decision core to the language rationale. https://clojure.org/about/rationale https://clojure.org/about/rationale > Customers and stakeholders have substantial investments in, and are comfortable with the performance, security and stability of, industry-standard platforms like the JVM. While Java developers may envy the succinctness, flexibility and productivity of dynamic languages, they have concerns about running on customer-approved infrastructure, access to their existing code base and libraries, and performance > symbiotic with an established Platform > VMs, not OSes, are the platforms of the future, providing: [...] * Libraries * Abstract away OSes * Huge set of facilities * Built-in and 3rd-party https://clojure.org/about/jvm_hosted https://clojure.org/about/jvm_hosted > Clojure is designed to be a hosted language, sharing the JVM type system, GC, threads etc. > Clojure is a great Java library consumer Where Clojure had nothing to bring, nothing was implemented, because interop is considered just as good, that's why there's not a lot of IO functions in core, and why math was missing for a long time.

eduction 4y ago
A good wrapper (like the Clojure version of java-time) can be a real lifesaver for those of us without Java backgrounds who don’t like having to learn deep and often baroque Java apis. I also use a pretty half baked wrapper someone wrote because I just about lost my mind trying to make sense of the class hierarchy it was wrapping. I think for people like Rich and Alex wrappers may look pointless because they already have invested in learning many of these APIs, know the patterns already, etc. For people like me from different language backgrounds they keep me from having to learn APIs with mutable state and deep class hierarchies and to me that’s a big win. (I rewrote this whole comment to hopefully be more concise.)
- 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).