Live data from Hacker News

Clojure builds as an amalgamation of orthogonal parts

blog.fogus.me

11–20 of 99 posts

Re: Clojure builds as an amalgamation of orthogonal parts

#11
post #3
post #2

Note to non-Clojurians: Most people just use Leiningen and don't mess with this stuff. This post does not paint a good picture of Clojure development tools, but don't get turned off by it. 99% of Clojure projects I've worked on just have a declarative project.clj file and building it is as simple as: $ lein uberjar I will never understand the core team's acute NIH Syndrome and tendency to fragment the community, but…

I've tried deps several times, but I keep coming back to leiningen. Can anyone explain the advantage of using deps to me? What I want from a build tool is: manage dependencies, starting a repl, running tests, and building a jar. Leiningen provides me this: lein repl, lein test, lein uberjar. Simple and exactly what I need, and importantly: i can expect that all leiningen projects use the same commands. Deps can be ma…

Exactly. Lein is like maven, declarative and just works in a standard way for 95% of use cases. Deps is like ant, can do anything, super flexible, but you need to start from scratch actually programming your build for every project.

Re: Clojure builds as an amalgamation of orthogonal parts

#12
post #4
post #2

Note to non-Clojurians: Most people just use Leiningen and don't mess with this stuff. This post does not paint a good picture of Clojure development tools, but don't get turned off by it. 99% of Clojure projects I've worked on just have a declarative project.clj file and building it is as simple as: $ lein uberjar I will never understand the core team's acute NIH Syndrome and tendency to fragment the community, but…

Hard agree here. As a full time Clojure dev, my experience is that lein "just works". I've also used the Clojure Tools professionally, and have seen the dev team lose countless days of what would be otherwise productive time putzing with it, building infrastructure that lein has had out-of-the-box for years, and trying to make sense out of its inscrutable docs. Want a project with both Clojure and Java? Want tests th…

I agree. To me tools.build is not a replacement for Lein at all. Lein is more intuitive to most beginners. It's much easier to tell someone to run `lein new some-app` and `lein run` / `lein uberjar`, than to tell them to configure their deps.edn file so they can run some alias with the `-X:...` / `-M` arg to create and run a new project (and who knows which dependency to use / configure to build an uberjar).

For experienced Clojure developers this might seem trivial, but new people (in my experience) are very impatient and want to get started ASAP. Honestly, who can blame them? Why does it have to be so difficult in this day and age?

Another thing I hear Clojure developers say is that beginners can start with Lein, but once you get more experienced with Clojure you can switch to tools.build. Why does a build tool need to be so unusable that you can only use it when you become more familiar with the language? You don't see that with Ruby's Bundler, or Elixir's Mix. They just work, just like Lein does.

Re: Clojure builds as an amalgamation of orthogonal parts

#13
post #3

Earlier quoted context omitted.

I've tried deps several times, but I keep coming back to leiningen. Can anyone explain the advantage of using deps to me? What I want from a build tool is: manage dependencies, starting a repl, running tests, and building a jar. Leiningen provides me this: lein repl, lein test, lein uberjar. Simple and exactly what I need, and importantly: i can expect that all leiningen projects use the same commands. Deps can be ma…

deps is extremely simple, which means very little time spent debugging, and it never breaks

I have never stressed over or debugged Leiningen in my 6 years of Clojure experience.

Not sure what you're on about.

Re: Clojure builds as an amalgamation of orthogonal parts

#14
post #4
post #2

Note to non-Clojurians: Most people just use Leiningen and don't mess with this stuff. This post does not paint a good picture of Clojure development tools, but don't get turned off by it. 99% of Clojure projects I've worked on just have a declarative project.clj file and building it is as simple as: $ lein uberjar I will never understand the core team's acute NIH Syndrome and tendency to fragment the community, but…

Hard agree here. As a full time Clojure dev, my experience is that lein "just works". I've also used the Clojure Tools professionally, and have seen the dev team lose countless days of what would be otherwise productive time putzing with it, building infrastructure that lein has had out-of-the-box for years, and trying to make sense out of its inscrutable docs. Want a project with both Clojure and Java? Want tests th…

> I'd argue the messy tooling they've been producing has probably been net negative value add to their community.

I feel the same way. It has definitely hurt the ecosystem.

Every Clojure IDE, for example, has to support a new deps/build system that is still a WIP and doesn't come with batteries.

Re: Clojure builds as an amalgamation of orthogonal parts

#15
post #2

Note to non-Clojurians: Most people just use Leiningen and don't mess with this stuff. This post does not paint a good picture of Clojure development tools, but don't get turned off by it. 99% of Clojure projects I've worked on just have a declarative project.clj file and building it is as simple as: $ lein uberjar I will never understand the core team's acute NIH Syndrome and tendency to fragment the community, but…

Leiningen is over 10 years old and has tons of pain points. For example, I bet you're not using ClojureScript, which is a mess of plugin debugging in leiningen. The goal of tools.build is to let you code your builds as simple functions that run at the REPL, which is awesome . No more finding misplaced keys in soup like https://github.com/technomancy/leiningen/blob/master/sample.... . If leiningen works for you, great…

That file says at the top:

  ;; This is an annotated reference of the options that may be set in a
  ;; project.clj file. It is fairly contrived in order to cover lots of
  ;; different options; it shouldn't be considered a representative
  ;; configuration.
The comment from ‘bm3719 makes tools.build sound like a less useful solution when compared to the practicality of leinengen, and your reply only has ClojureScript in its favor if I trust that the linked sample project.clj is indeed not representative (which matches my limited experience with my own “useful toy” projects and the other projects I have browsed). “awkward stuff like inlining strings of eval-ed clojure code in your build file” sounds really bad, but that could be equally contrived for all I know.

I also don’t understand the value of running builds from the REPL. What kind of developer process makes that a useful thing to have? What am I missing?

These are genuine questions, not advocacy for one thing or the other. I want to work professionally with Clojure(Script) enough that it is a prerequisite for me to consider changing jobs. I’ve only used lein thus far, so I don’t have enough experience with either tool to share a meaningful opinion here. I am extremely curious about the state of things though.

Re: Clojure builds as an amalgamation of orthogonal parts

#16
I don’t understand why deps was needed and I’m surprised its authors didn’t foresee the confusion it would create. I’m also confused as hell what I should be using now, and the idea of researching deps seems exhausting. I’ll just stick to cutting and pasting onto my leiningen config I think.

Re: Clojure builds as an amalgamation of orthogonal parts

#18
post #8

Earlier quoted context omitted.

Leiningen is over 10 years old and has tons of pain points. For example, I bet you're not using ClojureScript, which is a mess of plugin debugging in leiningen. The goal of tools.build is to let you code your builds as simple functions that run at the REPL, which is awesome . No more finding misplaced keys in soup like https://github.com/technomancy/leiningen/blob/master/sample.... . If leiningen works for you, great…

What pain points are those? Last I checked, doing cljs on Clojure Tools wasn't even possible. If that's still the case, then that's not a valid comparison (complex vs impossible). Also, that's the master version of project.clj, which is a superset of all possible features lein supports. Nobody's project.clj file looks like that, though I suspect you know this. Should we compare that complexity to a monster build.clj…

To be clear, you are pointing to this as an equally contrived example as what ‘dustingetz linked to, correct?

Re: Clojure builds as an amalgamation of orthogonal parts

#19
post #3
post #2

Note to non-Clojurians: Most people just use Leiningen and don't mess with this stuff. This post does not paint a good picture of Clojure development tools, but don't get turned off by it. 99% of Clojure projects I've worked on just have a declarative project.clj file and building it is as simple as: $ lein uberjar I will never understand the core team's acute NIH Syndrome and tendency to fragment the community, but…

I've tried deps several times, but I keep coming back to leiningen. Can anyone explain the advantage of using deps to me? What I want from a build tool is: manage dependencies, starting a repl, running tests, and building a jar. Leiningen provides me this: lein repl, lein test, lein uberjar. Simple and exactly what I need, and importantly: i can expect that all leiningen projects use the same commands. Deps can be ma…

I first used deps when doing a project with Datomic Cloud.

I like deps, but I can’t quite articulate why.

Re: Clojure builds as an amalgamation of orthogonal parts

#20
post #8

Earlier quoted context omitted.

What pain points are those? Last I checked, doing cljs on Clojure Tools wasn't even possible. If that's still the case, then that's not a valid comparison (complex vs impossible). Also, that's the master version of project.clj, which is a superset of all possible features lein supports. Nobody's project.clj file looks like that, though I suspect you know this. Should we compare that complexity to a monster build.clj…

To be clear, you are pointing to this as an equally contrived example as what ‘dustingetz linked to, correct?

Correct.
Post reply on HN