A bit of context, because your post could easily be taken in bad faith:
Ideally a multi-purpose tool like leiningen should be built on top of those simple parts
tools.build is 2 weeks old according to the announcement.
Leiningen is nearly 12 years old.
I haven't looked into tools.build, so not arguing for or against it.
Disclaimer: Have been doing some work on leiningen from time to time.
Also I first ran into Clojure in 2011, and while I liked the language, I simply loved how leiningen just worked and I was instantly a fan, not even thinking about how it's built, just nice for the users[0]. And I've always hated projects/ecosystems that made you jump through hoops or some arcane syntax and exploded half the times you tried to build. So "easy" is really important.
Still not sure I agree here, as long as it's flexible enough to let me get my work done.
The whole thing was "it must be simple, even if the user needs to spend more time learning it" which is only true for people who learn the thing and keep on using it. For us who come back to a project after months (because we switch between tech stacks) it might be just twice the amount of work, if you need to relearn it every time.
Comments
A bit of context, because your post could easily be taken in bad faith:
tools.build is 2 weeks old according to the announcement.
Leiningen is nearly 12 years old.
I haven't looked into tools.build, so not arguing for or against it.
Disclaimer: Have been doing some work on leiningen from time to time.
Also I first ran into Clojure in 2011, and while I liked the language, I simply loved how leiningen just worked and I was instantly a fan, not even thinking about how it's built, just nice for the users[0]. And I've always hated projects/ecosystems that made you jump through hoops or some arcane syntax and exploded half the times you tried to build. So "easy" is really important.
[0]: https://f5n.org/blog/2011/a-week-of-clojure/
"Easy" is important for someone to start playing around with something, to initially hook the user (the developer in this case).
But for professionals who spend a lot of time with the same tool, "simple" is more important in the long run.
Still not sure I agree here, as long as it's flexible enough to let me get my work done.
The whole thing was "it must be simple, even if the user needs to spend more time learning it" which is only true for people who learn the thing and keep on using it. For us who come back to a project after months (because we switch between tech stacks) it might be just twice the amount of work, if you need to relearn it every time.