3 ms·

I love Clojure, but I loathe Java, and I feel you do get exposed to a fair amount of Java stuff when trying to work in Clojure. It's far better than it used to

I love Clojure, but I loathe Java, and I feel you do get exposed to a fair amount of Java stuff when trying to work in Clojure. It's far better than it used to be, but it's still too much for my liking. Since I build stuff for the web (and Electron, a bit), I use ClojureScript, and am generally really happy with it. It's all the goodness of Clojure — the lispiness, the killer persistent data structures, the wonderfully well thought out standard library — plus the little bit of stuff I like from the JavaScript world — fast boot time, stuff I make can run on the web, good enough debugging/profiling tools, and all the included batteries of the web platform (for audio, video, React if you want it, etc). I personally use Figwheel to compile my CLJS and do live-reloading, but if I were starting today I'd probably use shadow-cljs. I like to do my own DOM stuff, but if you want to use React I'd do so via re-frame.

iLemming 7y ago
> you do get exposed to a fair amount of Java stuff Can you please expand on this? I've been using Clojure as my main PL for the past 3 years, and honestly only once I had to actually deal with some Java code (when I needed to figure out some Selenium stuff).
- thom 7y ago
  I have had to interact with Java regularly from Clojure. Many libraries have no Clojure bindings, e.g. XGBoost. Many libraries have wrappers that are incomplete or abandoned and so might need extending with Java interop, e.g. Java Topology Suite. Some gnarly stuff like mapping objects back and forth from JDBC requires understanding of the underlying Java types. I have found it necessary to understand different Java command line arguments and garbage collectors. More generally, I _like_ that I have the option of any JVM library. It’s an enormously broad and deep platform and Clojure is a very pragmatic way of exploiting all of that work.
  - iLemming 7y ago
    > I have had to interact with Java regularly from Clojure I guess it depends on what you're trying to build. For majority of Clojure devs, I think that's not the case.
- spiralganglion 7y ago
  When I learned Clojure, I also needed to learn about Maven, and POMs, and JARs, and the Java classpath, etc — and encountering all that stuff for the first time at the same time I was learning Clojure meant that I sometimes couldn't tell what concepts were part of Clojure, and what concepts were part of the Java ecosystem. This wasn't helped by the fact that the bulk of the "how to compile Clojure" documentation was written assuming a Java background (thus, assuming people would recognize the familiar Java stuff) — and when it wasn't, it didn't bother trying to explain what parts were handled by Java and why, because it assumed you didn't know Java so why bother explaining all that Java stuff that'll be foreign to you, let's just gloss over it. So the result was that I was unable to learn how to deal with the Java ecosystem parts of being a Clojure developer, so I had to go learn about the Java ecosystem separately. Contrast with ClojureScript — It has the same problems as above, but substitute JS for Java and NPM for Maven, etc. I was coming from a web background, so I could easily tell the JS-world from the CLJS-world. That familiarity helped me tremendously in getting up and running. The situation for CLJS is even better now with things like Planck and shadow-cljs (and Shaun Lebron's cljs/tool and Cuttle before them), since those tools mean you don't even need to install the JDK to get up and running with CLJS (as it should be, I'd argue). The situation for CLJ is a bit better thanks to the CLI tool. But the problems above could have been well handled by the classic non-technical solution: really, really good official docs. That's been getting better (thanks to Alex), but I'm pretty sure it's still going to be more painful to get up and running with CLJ or CLJS than Ruby, Node, etc., sadly.
  - Jach 7y ago
    Reminds me of a metric the Clojure community has used in judging itself, which is "time to first XML". There's now a helpful getting started page prominently linked from the home page, which has no XML on it, but it used to be https://clojure.org/community/downloads https://clojure.org/community/downloads was the main page and you'll note the XML is still there. You'd see that before you even set things up, you're clearly in Java town now, buddy... I like to use "time to first problem and the experience of its resolution" as my own ruler. Maybe it's an XML problem ("wtf is Maven?") but it's usually not until I try writing a program that I experience the first problem either at compile time or runtime. I haven't been keeping up with Clojure (whose latest version I've heard improved things on the error front) but when I first learned, it wasn't long before I made a mistake and paid for it with a giant Java stacktrace. I knew Java, though, so it wasn't a big deal to deal with it, but some instances were quite frustrating since there was a disconnect between useful messages about source locations when running code via a REPL connection versus launching the program from scratch which involves loading and running named Clojure files. It was rather subpar compared to Python, and especially to Common Lisp, which has useful compile-time warnings on top of a superior runtime error system. Still I've always thought it'd be foolish to dive into Clojure without some Java background, or at least without the anticipation of needing to get some Java background, so it's interesting to read the contrary on this page...

iLemming 7y ago

> you do get exposed to a fair amount of Java stuff Can you please expand on this? I've been using Clojure as my main PL for the past 3 years, and honestly only once I had to actually deal with some Java code (when I needed to figure out some Selenium stuff).

thom 7y ago
I have had to interact with Java regularly from Clojure. Many libraries have no Clojure bindings, e.g. XGBoost. Many libraries have wrappers that are incomplete or abandoned and so might need extending with Java interop, e.g. Java Topology Suite. Some gnarly stuff like mapping objects back and forth from JDBC requires understanding of the underlying Java types. I have found it necessary to understand different Java command line arguments and garbage collectors. More generally, I _like_ that I have the option of any JVM library. It’s an enormously broad and deep platform and Clojure is a very pragmatic way of exploiting all of that work.
- iLemming 7y ago
  > I have had to interact with Java regularly from Clojure I guess it depends on what you're trying to build. For majority of Clojure devs, I think that's not the case.
spiralganglion 7y ago
When I learned Clojure, I also needed to learn about Maven, and POMs, and JARs, and the Java classpath, etc — and encountering all that stuff for the first time at the same time I was learning Clojure meant that I sometimes couldn't tell what concepts were part of Clojure, and what concepts were part of the Java ecosystem. This wasn't helped by the fact that the bulk of the "how to compile Clojure" documentation was written assuming a Java background (thus, assuming people would recognize the familiar Java stuff) — and when it wasn't, it didn't bother trying to explain what parts were handled by Java and why, because it assumed you didn't know Java so why bother explaining all that Java stuff that'll be foreign to you, let's just gloss over it. So the result was that I was unable to learn how to deal with the Java ecosystem parts of being a Clojure developer, so I had to go learn about the Java ecosystem separately. Contrast with ClojureScript — It has the same problems as above, but substitute JS for Java and NPM for Maven, etc. I was coming from a web background, so I could easily tell the JS-world from the CLJS-world. That familiarity helped me tremendously in getting up and running. The situation for CLJS is even better now with things like Planck and shadow-cljs (and Shaun Lebron's cljs/tool and Cuttle before them), since those tools mean you don't even need to install the JDK to get up and running with CLJS (as it should be, I'd argue). The situation for CLJ is a bit better thanks to the CLI tool. But the problems above could have been well handled by the classic non-technical solution: really, really good official docs. That's been getting better (thanks to Alex), but I'm pretty sure it's still going to be more painful to get up and running with CLJ or CLJS than Ruby, Node, etc., sadly.
- Jach 7y ago
  Reminds me of a metric the Clojure community has used in judging itself, which is "time to first XML". There's now a helpful getting started page prominently linked from the home page, which has no XML on it, but it used to be https://clojure.org/community/downloads https://clojure.org/community/downloads was the main page and you'll note the XML is still there. You'd see that before you even set things up, you're clearly in Java town now, buddy... I like to use "time to first problem and the experience of its resolution" as my own ruler. Maybe it's an XML problem ("wtf is Maven?") but it's usually not until I try writing a program that I experience the first problem either at compile time or runtime. I haven't been keeping up with Clojure (whose latest version I've heard improved things on the error front) but when I first learned, it wasn't long before I made a mistake and paid for it with a giant Java stacktrace. I knew Java, though, so it wasn't a big deal to deal with it, but some instances were quite frustrating since there was a disconnect between useful messages about source locations when running code via a REPL connection versus launching the program from scratch which involves loading and running named Clojure files. It was rather subpar compared to Python, and especially to Common Lisp, which has useful compile-time warnings on top of a superior runtime error system. Still I've always thought it'd be foolish to dive into Clojure without some Java background, or at least without the anticipation of needing to get some Java background, so it's interesting to read the contrary on this page...