5 ms·

The context (per my limited understanding) is that Leiningen, the older and still quite popular way of scaffolding and packaging Clojure projects, is easy to us

The context (per my limited understanding) is that Leiningen, the older and still quite popular way of scaffolding and packaging Clojure projects, is easy to use but not simple; if you want it to do something a little different, it’s tricky because various tasks are complected together (I remember hearing this was due to its heavier reliance on Maven?). Meanwhile the newer and officially more blessed way of making projects, deps.edn, is simple but not easy; to do basic things you need to assemble the pieces yourself, but if you want to make your own custom build pipeline it’s probably more intuitive than Leiningen. borkdude’s new project seems to be trying to bridge the gap by providing some pre-canned equivalents of popular Leiningen commands, but built on top of deps.edn. Instead of lein this is neil. (I only use lein myself at the moment but curious about deps.edn)

user3939382 4y ago
Nice use of complected. Rich, is that you?
- LesZedCB 4y ago
  I think it has snuck into the diction of many of us who've seen his talks
brundolf 4y ago
When I briefly played with Clojure a few years ago, I was surprised and disappointed that there was no official toolchain (just the informally-agreed-upon leiningen, which it sounds like they're moving away from now?). It was bewildering and a turn-off for me as a new dev, and very surprising given how cohesive and practical the language and standard lib themselves are Easy or simple- I could see arguments for either. But I can't understand why they'd just punt on something so important in this day and age
- casion 4y ago
  tools.deps, which is mentioned above, is the official solution. It's been around for more than a few years.
  - brundolf 4y ago
    This was in mid 2019, so I'm not surprised things have evolved since then. It's good they've got an official solution now, but when official tooling only gets introduced to an ecosystem after the fact, there often ends up being a schism in the ecosystem that can keep hurting for a long time; just look at Python (it's far from a perfect comparison, but still). And the original comment reads like a confirmation that this is happening with Clojure: > Leiningen, the older and still quite popular way > borkdude’s new project seems to be trying to bridge the gap by providing some pre-canned equivalents of popular Leiningen commands, but built on top of deps.edn. Instead of lein this is neil. Maybe the story will be different for Clojure and people really will converge on the official solution eventually, who knows
    - didibus 4y ago
      I think in 2007, when Clojure first released, it wasn't common the way it is now that a language comes already with a full set of official tooling maintained alongside it. I feel this trend started later on. That said, it's also because Clojure is not its own runtime, so its actual tooling is the same as Java's. This is how it started, just expecting you'd use Maven as was standard in Java back then. Its the community that kind of decided they didn't like to use the Java tooling and on their own brought Clojars and Lein as replacement. So I think that's why at first there wasn't any, and later the core team thought, okay, well, if people want Clojure tooling and don't want to just Maven as maybe it was first intended, then they'd rather take it over and do it how they think is best. This is my interpretation of the history at least.
      - brundolf 4y ago
        That makes sense, thanks for the context
    - casion 4y ago
      Yes, there is a divide in the ecosystem for existing projects and knowledge, however new projects have a choice between two excellent, well documented and capable toolchains with sizable populations. I understand that as a beginner this is painful. You generally want to be told what to do with tooling, then ignore it for a while when you learn the language. As you mature as a developer in that ecosystem, the choices become a great benefit. It's true in Python as in C as in Common Lisp as in Clojure. I am a professional Clojure developer, and despite using Leiningen for many years I would say right now that I barely even know how to create a project or how to read a non-trivial project.clj. tools.deps on the other hand I feel confident with and believe it's one of the better systems out there. There are people who feel the opposite (in all ways), and I think that's _awesome_.

user3939382 4y ago

Nice use of complected. Rich, is that you?

LesZedCB 4y ago
I think it has snuck into the diction of many of us who've seen his talks

brundolf 4y ago

When I briefly played with Clojure a few years ago, I was surprised and disappointed that there was no official toolchain (just the informally-agreed-upon leiningen, which it sounds like they're moving away from now?). It was bewildering and a turn-off for me as a new dev, and very surprising given how cohesive and practical the language and standard lib themselves are Easy or simple- I could see arguments for either. But I can't understand why they'd just punt on something so important in this day and age

casion 4y ago
tools.deps, which is mentioned above, is the official solution. It's been around for more than a few years.
- brundolf 4y ago
  This was in mid 2019, so I'm not surprised things have evolved since then. It's good they've got an official solution now, but when official tooling only gets introduced to an ecosystem after the fact, there often ends up being a schism in the ecosystem that can keep hurting for a long time; just look at Python (it's far from a perfect comparison, but still). And the original comment reads like a confirmation that this is happening with Clojure: > Leiningen, the older and still quite popular way > borkdude’s new project seems to be trying to bridge the gap by providing some pre-canned equivalents of popular Leiningen commands, but built on top of deps.edn. Instead of lein this is neil. Maybe the story will be different for Clojure and people really will converge on the official solution eventually, who knows
  - didibus 4y ago
    I think in 2007, when Clojure first released, it wasn't common the way it is now that a language comes already with a full set of official tooling maintained alongside it. I feel this trend started later on. That said, it's also because Clojure is not its own runtime, so its actual tooling is the same as Java's. This is how it started, just expecting you'd use Maven as was standard in Java back then. Its the community that kind of decided they didn't like to use the Java tooling and on their own brought Clojars and Lein as replacement. So I think that's why at first there wasn't any, and later the core team thought, okay, well, if people want Clojure tooling and don't want to just Maven as maybe it was first intended, then they'd rather take it over and do it how they think is best. This is my interpretation of the history at least.
    - brundolf 4y ago
      That makes sense, thanks for the context
  - casion 4y ago
    Yes, there is a divide in the ecosystem for existing projects and knowledge, however new projects have a choice between two excellent, well documented and capable toolchains with sizable populations. I understand that as a beginner this is painful. You generally want to be told what to do with tooling, then ignore it for a while when you learn the language. As you mature as a developer in that ecosystem, the choices become a great benefit. It's true in Python as in C as in Common Lisp as in Clojure. I am a professional Clojure developer, and despite using Leiningen for many years I would say right now that I barely even know how to create a project or how to read a non-trivial project.clj. tools.deps on the other hand I feel confident with and believe it's one of the better systems out there. There are people who feel the opposite (in all ways), and I think that's _awesome_.