Clojure builds as an amalgamation of orthogonal parts • Hacker News Board

Re: Clojure builds as an amalgamation of orthogonal parts

#41

Post by seancorfield » Wed, Jul 21, 2021, 2:59 AM UTC

filoeleven wrote: post #21

fnordsensei wrote: post #19

Earlier quoted context omitted.

I first used deps when doing a project with Datomic Cloud. I like deps, but I can’t quite articulate why.

After using it with Datomic Cloud, do you prefer it also for local projects? Is there something that happened with Datomic Cloud configuration that made it “click” for you elsewhere? Did you just have to use it there and that experience informed your preferences? Data > functions > macros is a core concept of Clojure. Does that come into play here? These are prompts from a curious outsider’s perspective.

I haven't used Datomic at all but I do prefer the CLI and deps.edn for all my projects. I really haven't used Leiningen for years at this point -- I mostly only use it now when I'm helping a beginner debug some problem they've run into with Leiningen plugsin.

Re: Clojure builds as an amalgamation of orthogonal parts

#42

Post by geokon » Wed, Jul 21, 2021, 3:05 AM UTC

It's nice to have complex build/test setups with deep directory structures, I'm really happy this stuff exists and is being enhanced, but the flexibility kinda adds a barrier to getting started. It's also important to be able to just drop into a REPL, load some libraries and go.

I think the coolest thing in the pipeline is going to be `add-libs`: https://insideclojure.org/2018/05/04/add-lib/

I made a little orgmode literate demo that is selfcontained (no deps.edn) and even produces some inline SVG https://geokon-gh.github.io/literate-clojure.html

I hope this gets added into `core` and single file Clojure programs become a norm. Right now you still need to add tools.deps.alpha into your default user deps.ends for things to work. If this stuff gets into core you could finally send someone a file/gist and they could run it directly. I think that'd really improve the Clojure ecosystem. You can imagine sharing one-file issues/demos/examples and people don't need to reproduce your local setup or clone a whole repo

Re: Clojure builds as an amalgamation of orthogonal parts

#43

Post by Skinney » Wed, Jul 21, 2021, 3:15 AM UTC

filoeleven wrote: post #15

dustingetz wrote: post #5

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…

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…

Running builds from the repl let’s you skip the startup cost associated with Clojure. It’s faster if you need to run more than build command, or one build command several times.

Lein is easy to get started with, and for simple projects does everything you need. tools.build is endlessly flexible. For some projects, tools.build/tools.deps was much easier for me to use than leiningen (easier to just write clojure code directly than figuring out the whole lein plugin stuff). Use whatever works for you.

Re: Clojure builds as an amalgamation of orthogonal parts

#44

Post by billfruit » Wed, Jul 21, 2021, 3:55 AM UTC

This is good for clojure, I think. There was a time when lein seemed the preferred tool for clojure projects, but lein seemed to be doing too many different things, and more significantly was not packaged woth clojure. So during that time clojure felt batteries-not-included. With in built tooling, getting into and using clojure should be more easier.

Re: Clojure builds as an amalgamation of orthogonal parts

#45

Post by mpalmer » Wed, Jul 21, 2021, 4:25 AM UTC

cutler wrote: post #31

dustingetz wrote: post #25

Earlier quoted context omitted.

> RICH HICKEY: I think that, collectively, we are infatuated with these two notions of easy. We are just so self-involved in these two aspects; it's hurting us tremendously. Right? All we care about is, can I get this instantly and start running it in five seconds? It could be this giant hairball that you got, but all you care is, can you get it. Simple Made Easy is what attracted me to Clojure, and tools.build, tool…

You forget that on the ground-floor, where programming languages compete for mind-share, easy matters. In fact easy, in terms of getting something working, trumps difficult simplicity any day of the week. Easy is part of what makes an employer want to use your technology.

Bit bold to assume that the people making these decisions "forgot" anything. Design's about trade-offs.

The claim here is that the thing that makes your language easier to pick up initially nonetheless hobbles it for long-term use - refactoring, adding features. There is a business case for making the latter easy at the expense of the former.

Code can be easy or hard to write and/or change at various levels of complexity, and it's hard to solve for everything when designing a language.

Re: Clojure builds as an amalgamation of orthogonal parts

#46

Post by seancorfield » Wed, Jul 21, 2021, 5:10 AM UTC

seancorfield wrote: post #39

bm3719 wrote: 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…

That isn't a project deps.edn file though -- it's a compendium of tools that are available for the CLI/deps.edn and I put it together as a working example so folks coming to the CLI/deps.edn stuff could see the broad range of tools available and could copy'n'paste any useful bits they want. The README explains that and even links to a better-documented and more carefully curated set of aliases that folks might want t…

That should read "I use very, very FEW of those aliases"

Re: Clojure builds as an amalgamation of orthogonal parts

#47

Post by [deleted] » Wed, Jul 21, 2021, 5:52 AM UTC

dustingetz wrote: post #25

AtticHacker wrote: post #12

Earlier quoted context omitted.

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 expe…

> RICH HICKEY: I think that, collectively, we are infatuated with these two notions of easy. We are just so self-involved in these two aspects; it's hurting us tremendously. Right? All we care about is, can I get this instantly and start running it in five seconds? It could be this giant hairball that you got, but all you care is, can you get it. Simple Made Easy is what attracted me to Clojure, and tools.build, tool…

[deleted]

Re: Clojure builds as an amalgamation of orthogonal parts

#48

Post by brundolf » Wed, Jul 21, 2021, 6:09 AM UTC

Glad they're finally making this stuff first-party. When I messed around and did a Clojure project, the build/dependencies story was the biggest sour note of the experience by far. It was bewildering to have to go set up some third-party tool with a mustache logo before I could follow along with the official tutorial.

I think having a cohesive story for this is table-stakes in a modern programming language.

Re: Clojure builds as an amalgamation of orthogonal parts

#49

Post by modernerd » Wed, Jul 21, 2021, 6:12 AM UTC

seancorfield wrote: post #38

AtticHacker wrote: post #12

Earlier quoted context omitted.

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 expe…

We migrated from Leiningen to Boot and then to the CLI/deps.edn. Leiningen was too rigid and too much ceremony to write new tasks for. Boot was great from the "writing new tasks" point of view but the fileset abstraction and the pod pooling were both pain points for us. We've been very happy with the CLI and deps.edn and we're already using tools.build at work to streamline our (Clojure) build script. We have a fairl…

Thank you for the perspective (and also for clj-new — it feels like it should be built into Clojure’s own tooling).

Re: Clojure builds as an amalgamation of orthogonal parts

#50

Post by pjmlp » Wed, Jul 21, 2021, 6:33 AM UTC

bokchoi wrote: post #22

synthc wrote: 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…

It's like we learned nothing from years of suffering with snowflake Ant builds. Then again, gradle builds seems to be more popular than maven these days.

That is what happens when a new generation has grown without Ant and then a giant behemoth with endless cash for top hardware gets a deal to push Gradle as the official build tool for their mobile OS.