Item — HN Reader

> 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).

2 comments

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.

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 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...

I think things have changed for Clojure since you tried to learn it. You definitely never need to worry about POM or Maven.

Now, you still need to learn about a package manager and possibly a build tool. So substitute learning Maven for one of the Clojure ones: tools.deps, Leiningen, or Boot.

But I mean, you had to learn NPM one day as well no? And eventually Grunt or something like it, and WebPack, etc. Learning about a language's package manager and build tool is part of any learning of any language. But yes, if you already knew NPM and using ShadowCljs does mean you save yourself that part.

I'm not convinced that learning about how the JVM loads dependencies, gets packaged as Jars or UberJars, and how to use tools.deps or lein is any harder than what other languages force you to learn. So you're probably right in assuming the main issue is documentation not being tailored to very beginners.

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.

> 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.