4 ms·
Right, but running code to create configuration for other code, which is how I remember the build system working, is the same kind of inception-like abstraction
by doctor_eval 4y ago
Right, but running code to create configuration for other code, which is how I remember the build system working, is the same kind of inception-like abstraction that I was referring to.
As to that "no limits" thing: I see that as part of the problem and complexity of using Gradle. Everything is abstract and open. But at the point where you can do literally anything, maybe we'd be better off with a build library that we could just call from whatever language we're using? Why do we need another language to do "literally" anything?
- 411111111111111 4y agoI'd agree that a lot of the SMB/large enterprise software devleopment practices make trivial domain requirements into extremely complicated distributed monoliths colloquially called "microsrevices", but gradle is a pretty bad example for this kind of behaviour. gradle was created as a kneejerk reaction to maven forcing build configuration to be set in stone and in xml. Its inspired by dynamic scripting languages, which is as far removed from these companies as you can get. I remember it being created shortly after groovy became massively overhyped, and I think the only tools still using it are gradle and Jenkins...
- doctor_eval 4y agoTo be fair (to myself :) I was just saying that Gradle was a product of its time. It might not have all the problems of "enterprise" software from that period, but I certainly felt like it was overly general; almost as if it was an experiment in inverting configuration and code. I did actually prefer Gradle over Maven but in truth I found both to be pretty impenetrable.