3 ms·

> I do suspect that the survey is under-weighting how much beginners must struggle to navigate setting up CLASSPATH. If you don't come to Clojure from Java then

by mullr 8y ago

> I do suspect that the survey is under-weighting how much beginners must struggle to navigate setting up CLASSPATH. If you don't come to Clojure from Java then the toolchain is a bit intimidating with whatever a Maven is, followed by a process of trying to follow what both Java and Clojure tools are doing. This is one area Clojure compares very poorly with, eg, C (similarly awful setup process, but usually all the burden is shouldered by the distribution provider) or Python (use pip). The Clojure answer is similar to the python one: use lein. This basically solves all classpath issues. In the 3 years I used Clojure professionally, there were only small handful of times I had to deal with the classpath directly, and that was only for pretty exotic packaging issues. > It is interesting coming at Clojure from a Debian background at how resistant Leiningen has been to being integrated into the Debian apt archive. I think the package was removed in 2014 and only came back in 2018; so still isn't in the most recent stable. Given that Leiningen is itself probably the first choice of tool to manage dependencies, this raises questions about the technical underbelly of the tools used to build Clojure programs. What questions does it raise? Debian doesn't deal gracefully with any external dependency management systems, as far as I know.

puredanger 8y ago
The clj tool introduced with Clojure 1.9 is designed to help with exactly this problem. https://clojure.org/guides/deps_and_cli https://clojure.org/guides/deps_and_cli
roenxi 8y ago
> The Clojure answer is similar to the python one: use lein. This basically solves all classpath issues. Most of them. I struggled a lot with the specific case of "I have jogl installed through apt and I want to use it in a Clojure lein setup". > In the 3 years I used Clojure professionally That is why I think the issue is underappreciated. Java provides a very comprehensive set of concepts to deal with making Java code run everywhere, and that sort of thing is just baggage when trying to learn a language as an amateur on one system. I expect it becomes a feature when something needs to be done professionally and platform is no longer a given. > What questions does it raise? * In a language that requires a lot of probably-new mental models to understand, how much extra burden is created if mistakes are made configuring dependency management? * Can a novice successfully identify what is going wrong if they muck up their dependencies in a 3rd party tool? * Will a novice identify that they should be using a 3rd party tool to manage their dependencies, rather than relying on other mechanisms that might be familiar to them? * Is the hosted nature of Clojure creating interesting new failure modes for novices in the build system as issues might now straddle two languages? These aren't questions that a professional would encounter, I expect being across complicated build systems is sort of how things are. But the leap from pure Clojure, having fun in the repl, to pure Clojure + a library is a very steep learning curve. The quality of the project setup has to go up a long way. At the moment, based purely on that learning curve, it must be one of the early barriers that causes beginners to drop the language. I'm surprised it doesn't get mentioned in the survey. Watching Rich's talks, I always got the impression that dependencies in general are an outstanding to-be-thought-about problem. > Debian doesn't deal gracefully with any external dependency management systems, as far as I know. External dependency management systems fail to meet Debian user's expectations of quality and stability, tyvm :). Yeah, you're right.
- deleted 8y ago
  [deleted]
- mullr 8y ago
  I've struggled with jogl as well. Clojure being hosted is a definitely a double-edged sword; while it makes it possible to use something like jogl, actually doing so can require you know something (or a lot of things) about the underlying platform. The questions you raise here are real issues. I've been able to scaffold things for newcomers to the language in the past, but I can easily imagine how they could go off the rails without some guidance. I believe that the new "deps.edn" mechanism is meant to be the official, paved path for dependency and platform interaction in the future. But until everybody is using it, there will be two ways of doing things and the confusions that goes with having a choice. Perhaps it's necessary to move the platform forward.

by mullr 8y ago

puredanger 8y ago

The clj tool introduced with Clojure 1.9 is designed to help with exactly this problem. https://clojure.org/guides/deps_and_cli https://clojure.org/guides/deps_and_cli

roenxi 8y ago

> The Clojure answer is similar to the python one: use lein. This basically solves all classpath issues. Most of them. I struggled a lot with the specific case of "I have jogl installed through apt and I want to use it in a Clojure lein setup". > In the 3 years I used Clojure professionally That is why I think the issue is underappreciated. Java provides a very comprehensive set of concepts to deal with making Java code run everywhere, and that sort of thing is just baggage when trying to learn a language as an amateur on one system. I expect it becomes a feature when something needs to be done professionally and platform is no longer a given. > What questions does it raise? * In a language that requires a lot of probably-new mental models to understand, how much extra burden is created if mistakes are made configuring dependency management? * Can a novice successfully identify what is going wrong if they muck up their dependencies in a 3rd party tool? * Will a novice identify that they should be using a 3rd party tool to manage their dependencies, rather than relying on other mechanisms that might be familiar to them? * Is the hosted nature of Clojure creating interesting new failure modes for novices in the build system as issues might now straddle two languages? These aren't questions that a professional would encounter, I expect being across complicated build systems is sort of how things are. But the leap from pure Clojure, having fun in the repl, to pure Clojure + a library is a very steep learning curve. The quality of the project setup has to go up a long way. At the moment, based purely on that learning curve, it must be one of the early barriers that causes beginners to drop the language. I'm surprised it doesn't get mentioned in the survey. Watching Rich's talks, I always got the impression that dependencies in general are an outstanding to-be-thought-about problem. > Debian doesn't deal gracefully with any external dependency management systems, as far as I know. External dependency management systems fail to meet Debian user's expectations of quality and stability, tyvm :). Yeah, you're right.

deleted 8y ago
[deleted]
mullr 8y ago
I've struggled with jogl as well. Clojure being hosted is a definitely a double-edged sword; while it makes it possible to use something like jogl, actually doing so can require you know something (or a lot of things) about the underlying platform. The questions you raise here are real issues. I've been able to scaffold things for newcomers to the language in the past, but I can easily imagine how they could go off the rails without some guidance. I believe that the new "deps.edn" mechanism is meant to be the official, paved path for dependency and platform interaction in the future. But until everybody is using it, there will be two ways of doing things and the confusions that goes with having a choice. Perhaps it's necessary to move the platform forward.