5 ms·

I've posted this quote before, but it might help explain why making Clojure easier to get into maybe hasn't been a priority for Hickey et al. So we need player

by adamkl 6y ago

I've posted this quote before, but it might help explain why making Clojure easier to get into maybe hasn't been a priority for Hickey et al. So we need players. I would rant here, but I won't. But look at this guitar player with blisters. A harpist has blisters, a base player with blisters. There's this barrier to overcome for every musician. Imagine if you downloaded something from GitHub and it gave you blisters. - Rich Hickey (Design, Composition and Performance) Clojure seems more concerned with power, expressiveness, and reach, rather than ease of use. Does this alienate new users, sure, but the Clojure community seems OK with that as a trade-off.

deleted 6y ago
[deleted]
gfxgirl 6y ago
That assumes it is a tradeoff. Maybe you can have both. I see nothing obviously preventing having power, expressiveness, and reach, and ease of use
- adamkl 6y ago
  I agree that it doesn't have to be a trade-off, but that mindset might explain why there is less focus on creating one-click installers. An example would be Clojure's newish approach to managing projects via the CLI and deps.edn. It's very powerful, and expressive, but definitely not a one-click approach.
  - roenxi 6y ago
    Clojure is an inspirational language that has some insightful opinions about how things should be done. A month spent learning Clojure is a great investment. A lifetime programming in Clojure would be a joy. But as I recall the original Rich Hickey talks on "Why Clojure?" he was explicit that dependency/project management were very hard problems that Clojure didn't really attempt to solve. I'm not aware of any Clojure tools that are best-of-breed for project management. Java has a better model for locking everything down (or maybe how the Linux Distros manage their repositories) and Python has a better model for just keeping up with the current state of things. I'm not aware of any half-and-half model that gives satisfying results. Clojure is inferior to Java in that aspect because the number of things to keep track of roughly doubles (for every concept there seems to be a Clojure version and a Java version) and library management is bizarre and warty - see also the horrible import/require/use/some other one I can't even remember mess. And then there is unpicking the syntax differences between using things in the (ns) macro vs calling direct. I dunno; maybe something changed but that part of the experience is a mess. Unusually poorly done in Clojure too, everything else was so lovely. I never got on top of it and I tried for months; as evidenced I can't even remember how to load a library after putting it down for a little while. Even assuming the classpath is correctly set. What would have to happen for a C programmer to forget #include "name.h" ?
    - microcolonel 6y ago
      > he was explicit that dependency/project management where very hard problems that Clojure didn't really attempt to solve. For what it's worth, having used Clojure for work for a couple years now, and ditching leiningen for deps.edn (built in package and dependency management that hooks into maven), I've not had an issue with it. You just add the dependencies to your deps.edn, and run your program. If your namespace needs something from a package, you add it to the (:require ...) section of your ns declaration. Here's an example ns from one of our messiest modules: (ns profusion.core (:require [clojure.core.match :refer [match]] [clojure.set :as set] [clojure.string :as string] [clojure.walk :as walk] [clojure.zip :as z] [instaparse.core :as insta] [profusion.infix :refer [infix-to-prefix]] [profusion.standard-library :refer [comparison]] [profusion.utils :refer :all] ) (:import (org.jgrapht Graph) (org.jgrapht.traverse TopologicalOrderIterator) (org.jgrapht.graph DefaultEdge SimpleDirectedGraph) )) To be clear, projects like this can be run with the base Clojure distribution, no additional tools required. > I'm not aware of any Clojure tools that are best-of-breed for project management. Java has a better model for locking everything down (or maybe how the Linux Distros manage their repositories) and Python has a better model for just keeping up with the current state of things. I'm not aware of any half-and-half model that gives satisfying results. deps.edn generally asks you for specific versions if you're getting things from maven, so you don't risk not "locking everything down". If you really want to lock everything down however, you should check all your dependencies into your source tree, this is an option that deps.edn supports well, through the :local keyword instead of :mvn/version for maven dependencies. That namespace declaration I showed you is from a subproject that we import into one of our other subprojects using the :local keyword, and the deps.edn for it just declares the source directories and and the dependencies, everything else is handled automatically.
      - roenxi 6y ago
        That is a perfectly reasonable way of doing things. However, the official reference [0] recommends: (1) Your way (but also throw in an :only and doesn't mention :refer) (2) (require 'clojure.contrib.def 'clojure.contrib.except 'clojure.contrib.sql) (3) (require '(clojure.contrib def except sql)) And leaves open a lot of room for someone to try to use (use) which is probably a mistake since you don't use it. And sometimes your way has [] and sometimes it doesn't. Pretty much at random considering '[profusion.utils :refer :all]'. And the official docs add in a dizzying number of combinations of quoting requirements to recall. It isn't the end of the world but that is a far cry from how good all the other parts of the language are. It is really sloppy and confusing to learn. There is no recommended approach and I personally can't remember which easy way I used last time so my personal projects cycle randomly. I think Clojure has the worst library loading mechanism of any language I think is good. Even your way has two completely different code paths (import vs require) to bring in dependencies. [0] https://clojure.org/reference/libs https://clojure.org/reference/libs
nickbauman 6y ago
If you're not familiar with the JVM, I think this is a big ask for most people as far as ease is concerned. I have created a template on my github to use clojurescript with your typical NPM setup that would allow you to get started right away. I know of no equivalent in the JVM world mostly because of how tightly Oracle controls the download experience of the JDK.
- satya71 6y ago
  Well, Oracle JDK is a non-starter outside enterprise settings these days. You should be using Zulu or Corretto, and both are much easier to download.
  - james-mcelwain 6y ago
    No, you should almost certainly be using openjdk, which oracle jdk is based off, unless you have a compelling reason an alternative implementation is better.
    - TJSomething 6y ago
      Zulu and Corretto are both distributions of OpenJDK.
    - satya71 6y ago
      OpenJDK releases become unmaintained as soon as a new release comes out, not ideal for anyone who cares about stability. Zulu and Corretto backport bug and security fixes to supported releases.
alharith 6y ago
False choice. Guitar Center sells out of the box integrated guitar + amp combos with a getting started booklet. You can also use 9 gauge strings. Those _might_ give you a slight callus, but certainly no blisters.
rfrey 6y ago
I am full to my neckline with Clojure kool-aid: I love the language and programming experience. But the "getting started" your parent is referring to, IMO, is getting the tooling set up, getting the repls connected, figuring out what a full-stack app looks like with its 2 distinct repls and toolchains and lein config mashups, hooking up an editor... and then having it break the next day. After 5 years of Clojure I still get frustrated if I'm away for more than a month. It's like you were getting blisters from stringing your guitar. You buy a guitar, get home, and it takes three days to open the case. Then another week to figure out which strings go where. God help you when you realize you have to tune the thing. Two, five, seven days pass and you haven't played a note. I don't think that's what Hickey meant. That said, it's worth it.
- tartoran 6y ago
  Spot on with your amusing guitar analogy. Getting to play notes seems like an afterthought, but when it does it plays for you as if it reads your mind to do so. The problem is the setup and that's the part that I dislike these days, the patience to to configure the tools is not there, a lot of the tools are like black boxes, something goes wrong and it isn't visible or or it is too complex to enjoy the process.
deleted 6y ago
[deleted]
octetta 6y ago
Thanks for sharing this... I'd never seen it before. It does make me wonder how many languages we use that could be compared to bag-pipes... in that even when you learn how to play them expertly, they still sound like an animal being killed.
scotty79 6y ago
What turned me of from clojure when I tried it last time was "Why my trivial syntax errors like unmatched brackets or easy semantic errors like wrong number of parameters to 'built in' functiins blow up in my face with java stack that involves some parser or something only after I 'lein run' the program?" I used vs code with most popular clojure plugin and I was expecting more.

by adamkl 6y ago

deleted 6y ago

[deleted]

gfxgirl 6y ago

That assumes it is a tradeoff. Maybe you can have both. I see nothing obviously preventing having power, expressiveness, and reach, and ease of use

adamkl 6y ago
I agree that it doesn't have to be a trade-off, but that mindset might explain why there is less focus on creating one-click installers. An example would be Clojure's newish approach to managing projects via the CLI and deps.edn. It's very powerful, and expressive, but definitely not a one-click approach.
- roenxi 6y ago
  Clojure is an inspirational language that has some insightful opinions about how things should be done. A month spent learning Clojure is a great investment. A lifetime programming in Clojure would be a joy. But as I recall the original Rich Hickey talks on "Why Clojure?" he was explicit that dependency/project management were very hard problems that Clojure didn't really attempt to solve. I'm not aware of any Clojure tools that are best-of-breed for project management. Java has a better model for locking everything down (or maybe how the Linux Distros manage their repositories) and Python has a better model for just keeping up with the current state of things. I'm not aware of any half-and-half model that gives satisfying results. Clojure is inferior to Java in that aspect because the number of things to keep track of roughly doubles (for every concept there seems to be a Clojure version and a Java version) and library management is bizarre and warty - see also the horrible import/require/use/some other one I can't even remember mess. And then there is unpicking the syntax differences between using things in the (ns) macro vs calling direct. I dunno; maybe something changed but that part of the experience is a mess. Unusually poorly done in Clojure too, everything else was so lovely. I never got on top of it and I tried for months; as evidenced I can't even remember how to load a library after putting it down for a little while. Even assuming the classpath is correctly set. What would have to happen for a C programmer to forget #include "name.h" ?
  - microcolonel 6y ago
    > he was explicit that dependency/project management where very hard problems that Clojure didn't really attempt to solve. For what it's worth, having used Clojure for work for a couple years now, and ditching leiningen for deps.edn (built in package and dependency management that hooks into maven), I've not had an issue with it. You just add the dependencies to your deps.edn, and run your program. If your namespace needs something from a package, you add it to the (:require ...) section of your ns declaration. Here's an example ns from one of our messiest modules: (ns profusion.core (:require [clojure.core.match :refer [match]] [clojure.set :as set] [clojure.string :as string] [clojure.walk :as walk] [clojure.zip :as z] [instaparse.core :as insta] [profusion.infix :refer [infix-to-prefix]] [profusion.standard-library :refer [comparison]] [profusion.utils :refer :all] ) (:import (org.jgrapht Graph) (org.jgrapht.traverse TopologicalOrderIterator) (org.jgrapht.graph DefaultEdge SimpleDirectedGraph) )) To be clear, projects like this can be run with the base Clojure distribution, no additional tools required. > I'm not aware of any Clojure tools that are best-of-breed for project management. Java has a better model for locking everything down (or maybe how the Linux Distros manage their repositories) and Python has a better model for just keeping up with the current state of things. I'm not aware of any half-and-half model that gives satisfying results. deps.edn generally asks you for specific versions if you're getting things from maven, so you don't risk not "locking everything down". If you really want to lock everything down however, you should check all your dependencies into your source tree, this is an option that deps.edn supports well, through the :local keyword instead of :mvn/version for maven dependencies. That namespace declaration I showed you is from a subproject that we import into one of our other subprojects using the :local keyword, and the deps.edn for it just declares the source directories and and the dependencies, everything else is handled automatically.
    - roenxi 6y ago
      That is a perfectly reasonable way of doing things. However, the official reference [0] recommends: (1) Your way (but also throw in an :only and doesn't mention :refer) (2) (require 'clojure.contrib.def 'clojure.contrib.except 'clojure.contrib.sql) (3) (require '(clojure.contrib def except sql)) And leaves open a lot of room for someone to try to use (use) which is probably a mistake since you don't use it. And sometimes your way has [] and sometimes it doesn't. Pretty much at random considering '[profusion.utils :refer :all]'. And the official docs add in a dizzying number of combinations of quoting requirements to recall. It isn't the end of the world but that is a far cry from how good all the other parts of the language are. It is really sloppy and confusing to learn. There is no recommended approach and I personally can't remember which easy way I used last time so my personal projects cycle randomly. I think Clojure has the worst library loading mechanism of any language I think is good. Even your way has two completely different code paths (import vs require) to bring in dependencies. [0] https://clojure.org/reference/libs https://clojure.org/reference/libs

nickbauman 6y ago

If you're not familiar with the JVM, I think this is a big ask for most people as far as ease is concerned. I have created a template on my github to use clojurescript with your typical NPM setup that would allow you to get started right away. I know of no equivalent in the JVM world mostly because of how tightly Oracle controls the download experience of the JDK.

satya71 6y ago
Well, Oracle JDK is a non-starter outside enterprise settings these days. You should be using Zulu or Corretto, and both are much easier to download.
- james-mcelwain 6y ago
  No, you should almost certainly be using openjdk, which oracle jdk is based off, unless you have a compelling reason an alternative implementation is better.
  - TJSomething 6y ago
    Zulu and Corretto are both distributions of OpenJDK.
  - satya71 6y ago
    OpenJDK releases become unmaintained as soon as a new release comes out, not ideal for anyone who cares about stability. Zulu and Corretto backport bug and security fixes to supported releases.

alharith 6y ago

False choice. Guitar Center sells out of the box integrated guitar + amp combos with a getting started booklet. You can also use 9 gauge strings. Those _might_ give you a slight callus, but certainly no blisters.

rfrey 6y ago

I am full to my neckline with Clojure kool-aid: I love the language and programming experience. But the "getting started" your parent is referring to, IMO, is getting the tooling set up, getting the repls connected, figuring out what a full-stack app looks like with its 2 distinct repls and toolchains and lein config mashups, hooking up an editor... and then having it break the next day. After 5 years of Clojure I still get frustrated if I'm away for more than a month. It's like you were getting blisters from stringing your guitar. You buy a guitar, get home, and it takes three days to open the case. Then another week to figure out which strings go where. God help you when you realize you have to tune the thing. Two, five, seven days pass and you haven't played a note. I don't think that's what Hickey meant. That said, it's worth it.

tartoran 6y ago
Spot on with your amusing guitar analogy. Getting to play notes seems like an afterthought, but when it does it plays for you as if it reads your mind to do so. The problem is the setup and that's the part that I dislike these days, the patience to to configure the tools is not there, a lot of the tools are like black boxes, something goes wrong and it isn't visible or or it is too complex to enjoy the process.

deleted 6y ago

[deleted]

octetta 6y ago

Thanks for sharing this... I'd never seen it before. It does make me wonder how many languages we use that could be compared to bag-pipes... in that even when you learn how to play them expertly, they still sound like an animal being killed.

scotty79 6y ago

What turned me of from clojure when I tried it last time was "Why my trivial syntax errors like unmatched brackets or easy semantic errors like wrong number of parameters to 'built in' functiins blow up in my face with java stack that involves some parser or something only after I 'lein run' the program?" I used vs code with most popular clojure plugin and I was expecting more.