Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure builds as an amalgamation of orthogonal parts

blog.fogus.me

Post reply on HN
Print view View original

51–60 of 99 posts

Re: Clojure builds as an amalgamation of orthogonal parts

#51

Post by john-shaffer »

beders wrote: post #26
dustingetz wrote: post #9

Earlier quoted context omitted.

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

deps can't produce stable builds as it insists dependencies are not ordered. Yet on the classpath they are. That order shouldn't matter, but it very well does. lein AFAIK produces the same classpath every time. deps: Maybe put the paths first and then let's gamble what a seq on a map produces...

That appears to have been true for only about a month: https://groups.google.com/g/clojure/c/WI3ddZRK4Bg/m/RtJVt3IZ...

https://github.com/clojure/tools.deps.alpha/commit/c22ad46c6...

Re: Clojure builds as an amalgamation of orthogonal parts

#52

Post by seancorfield »

modernerd wrote: post #49
seancorfield wrote: post #38

Earlier quoted context omitted.

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).

Now that tools.build is here, I think clj-new can be substantially simplified (copy-dir with text replacement is most of what clj-new does for built-in templates) and when add-libs gets to the main branch of t.d.a or Clojure itself, that takes care of a lot of the rest of what clj-new does.

Re: Clojure builds as an amalgamation of orthogonal parts

#53

Post by seancorfield »

divs1210 wrote: post #14
bm3719 wrote: post #4

Earlier quoted context omitted.

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.

Start a REPL; connect to it. That's identical for every single editor/IDE. The problem is that editor plugin maintainers seem reluctant to encourage developers to start REPLs manually so they have to deal with the whole issue of "how to start a REPL" -- which should be up to the developer, not the tool.

I run REPLs for weeks, sometimes months, so I don't want my editor to start my REPL since my editor is going to get restarted a lot more often than my REPLs!

Re: Clojure builds as an amalgamation of orthogonal parts

#54

Post by vore »

pjmlp wrote: post #50
bokchoi wrote: post #22

Earlier quoted context omitted.

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.

I would think that Gradle is a lot more pleasant to use than Ant...

Re: Clojure builds as an amalgamation of orthogonal parts

#55

Post by fnordsensei »

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 do.

I guess it boils down to the fact that I don't find it significantly harder to use than Leiningen, there are great libraries and tools that work well with it (shadow-cljs can source its deps from deps.edn for example), and I wrap the entire thing in a task system anyway (lately, Babashka tasks).

I guess it helps that its the "official" way to do things, but that's not a primary concern for me.

Re: Clojure builds as an amalgamation of orthogonal parts

#56

Post by pjmlp »

vore wrote: post #54
pjmlp wrote: post #50

Earlier quoted context omitted.

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.

I would think that Gradle is a lot more pleasant to use than Ant...

Not for those that don't suffer from XML allergy, so given that, the outcome is almost the same, with the caveat that Gradles uses a ton of more resources than Ant, as it needs its background daemon sucking up 2GB to pretend being fast.

Re: Clojure builds as an amalgamation of orthogonal parts

#57

Post by jarcane »

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…

Rich can try to redefine the English language all he wants, but he'll find it a lot more difficult than redefining Clojure.

The fact is, the solutions the core team have been putting out for the last several years have been neither simple or easy, and in fact tend towards a weird and arcane complexity in service of problems no one seemed to have.

I remain baffled by Spec, by the clj tool, by deps, and now this. At every step it seems as if the team lives in their own world, and not in ours, and each new tool is as cryptic and convoluted as the last.

They frequently don't even seem to encourage code that is consistently idiomatic to how the rest of us even write Clojure. Who else was even using namespaced keywords for anything until Spec decided to not only use them, but link the entire mechanism to a mutable namespace registry? How is that "functional" in any way?

Re: Clojure builds as an amalgamation of orthogonal parts

#58

Post by roenxi »

fungiblecog wrote: post #28

What all the critics miss is that Lein is "Easy" but tools.deps, tools.build are "Simple". Rich wants all of clojure to be built from simple orthogonal parts that compose together. Ideally a multi-purpose tool like leiningen should be built on top of those simple parts. Other tools can re-use those parts in different ways. With Leiningen - its a great tool but it's a complex thing that you take on an all-or-nothing b…

Theory is all very well, but adding a library to a project is a critical requirement for all projects. A new starter comes over to Clojure from Python and the Deps guide [0] confidently explains too them that they add

{:deps {clojure.java-time/clojure.java-time {:mvn/version "0.3.2"}}}

to their deps.edn and they're good to go. Raising only the questions of:

1. What are the available keys of this map?

2. Why do I have to repeat clojure.java-time twice? Is this arbitrary? When are these different? (turns out it depends, if anyone is trying to figure that out)

3. What is a ":mvn"?

4. Is there a list of libraries I should be consulting to work out what versions mvn supports?

5. Is mvn my only choice here? Are there other repositories?

6. The map is one of Clojure's most flexible data structures because it can take arbitrary keys. Circling back to 1 - What other keys are supported?

Answering 1/6 is particularly interesting because the Deps reference [1] is long, undecipherable and frankly not-very-well written reference material. It starts off as more of a tutorial than a reference and requires the reader to engage with how Clojure programs run rather than how to download a library.

Someone coming over from Python would look at this, recall "pip install library" and then a lot of them would do the sensible thing and give up. Potentially never realising that the correct thing to do is go with leiningen. I'm not even sure if pip has command line flags, I've basically never been exposed to them.

Simple is all very good, I'm sure the people who struggle through to figure out how deps actually works are the better for it, but it would be better if adding a library were easy as well as simple.

[0] https://clojure.org/guides/deps_and_cli#_running_a_repl_and_...

[1] https://clojure.org/reference/deps_and_cli

Re: Clojure builds as an amalgamation of orthogonal parts

#59

Post by weavejester »

roenxi wrote: post #58
fungiblecog wrote: post #28

What all the critics miss is that Lein is "Easy" but tools.deps, tools.build are "Simple". Rich wants all of clojure to be built from simple orthogonal parts that compose together. Ideally a multi-purpose tool like leiningen should be built on top of those simple parts. Other tools can re-use those parts in different ways. With Leiningen - its a great tool but it's a complex thing that you take on an all-or-nothing b…

Theory is all very well, but adding a library to a project is a critical requirement for all projects. A new starter comes over to Clojure from Python and the Deps guide [0] confidently explains too them that they add {:deps {clojure.java-time/clojure.java-time {:mvn/version "0.3.2"}}} to their deps.edn and they're good to go. Raising only the questions of: 1. What are the available keys of this map? 2. Why do I have…

While I agree that Leiningen is easier to get going with, many of the questions you asked also apply to Leiningen's project file.

I use Leiningen as it's convenient, but I check back on the tools.* ecosystem occasionally to see the progress being made. My suspicion is that tools.* will eventually supersede Leiningen and Boot, but that it will take two to three years at least.

Currently it's easier to use "lein new", but I can imagine a Babashka wrapper around tools.deps and tools.build eventually supplanting this. Being able to write, for example:

    bbb new foobar; cd foobar; bbb add clojure.java.time
to automatically generate and update a deps.edn would be convenient, and potentially with far lower latency than Lein.

Re: Clojure builds as an amalgamation of orthogonal parts

#60

Post by synthc »

fungiblecog wrote: post #28

What all the critics miss is that Lein is "Easy" but tools.deps, tools.build are "Simple". Rich wants all of clojure to be built from simple orthogonal parts that compose together. Ideally a multi-purpose tool like leiningen should be built on top of those simple parts. Other tools can re-use those parts in different ways. With Leiningen - its a great tool but it's a complex thing that you take on an all-or-nothing b…

Simple and easy are not mutually exclusive, and simple software is not automatically good software. Other criteria, ease of use, documentation, also matter, especially for a build tool intended to be used by a whole community.

At the moment deps feels more of a 'make your own build tool' kit. Simple, sure, but not easy to use: you need to tell it how to build jars or run tests, which is IMO essential functionality of a build tool.

I don't want to tell my build tool how to achieve these essential things, and risk ending up with a mess of projects that all use different aliases to run different tests runners and different jar building plugins. Build tooling is one place where convention over configuration matters to me, and why I still prefer leiningen.

I'm hoping deps and tools.build will evolve from a 'make your own build tool kit' to a build tool that exposes the kit it was built on, so that most projects don't require anything custom, and be flexible enoug so that one special project can leverage the 'simple orthogonal parts' in the kit.

I see tools.build as a step forwards, but it's not there yet IMO, the user still needs to configure a bunch of stuff to get essential functionality.

I hope the core team will make a build tool on top of the 'make your own build tool kit' that is deps and tools.build, that comes with good defaults and essential features for the common projects, while exposing the 'simple orthogonal parts' in the kit so these can be used for complex projects.

Post reply on HN