4 ms·

> Everything is action-at-a-distance and implicit. And this was the idiomatic way to build "enterprise" software a few years ago, right? Inversion of control,

> Everything is action-at-a-distance and implicit. And this was the idiomatic way to build "enterprise" software a few years ago, right? Inversion of control, automatic dependency injection, service discovery, configuration over code, builder patterns, ORMs, DSLs, and on and on. The idea seemed to be that, if we just keep adding abstraction and complexity to our tools, soon enough we would be able to build an entire systems with one just-so line of code. I'm not justifying it, but Gradle really was a product of the times. I used it for years but never understood it, and always hated it only slightly less than Maven. It's like we got captured by the tools.

411111111111111 4y ago
> this was the idiomatic way to build "enterprise" software a few years ago, right? Inversion of control, automatic dependency injection, service discovery, configuration over code, builder patterns, ORMs, DSLs, and on and on. All of that remains true for enterprise today as well. And for the record, Gradle doesn't really check any of the marks you just listed, only DSL if you are squinting a little. Gradle is basically a application to run generic groovy code. There are literally no limits to what you can do, as you've got a full JVM to play with.
- 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 ago
    I'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 ago
      To 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.
surgical_fire 4y ago
> always hated it only slightly less than Maven. I used to dislike Maven until I was forced to work on a large codebase with Gradle. Now I think Maven is actually quite good.
MilStdJunkie 4y ago
"Captured by the tools" . . I am stealing that one! Whew, yeah, I stepped away from Gradle once I got the keys for our company's Jenkins instance. Jenkins was . . its own . . bag of rats . . but at least it was somewhat predictable. "Captured by the tools". You've described big label tech comms software from the last fifteen - nay, twenty - years. A . . frickin ECOSYSTEM . . an entire industry that outspends content creation several times over . . a vast panoply of ten thousand page specifications and eye-wateringly-expensive tooling . . all for making . . DOCUMENTS. For making documents. WHY DOES THIS EXIST. Actually, there's a reason. But it's not a functional reason or a technical reason; it's economics, culture, a whole maze of perverse incentives. Which is why it's so frustrating. I'm working on a presentation for exactly this, and it's been really cathartic.
- doctor_eval 4y ago
  This is exactly right. Why should my build tool require more study than the language I’m working in? Why do I need to learn a wholly language to build? In the same vein, why should the ORM be more complex than the database? Why should the application server be orders of magnitude more complex than my code? I mean - I do understand the reasons as given - I just don’t agree that the solutions are worth the sacrifices. I should not need a two week course to be good at some ancillary tool. This morning I started thinking about this thread and what I use today. I don’t even notice the build and dependency system in Go. It’s just there, and it works. Easy things are easy, hard things are possible, and performance is important.

411111111111111 4y ago

> this was the idiomatic way to build "enterprise" software a few years ago, right? Inversion of control, automatic dependency injection, service discovery, configuration over code, builder patterns, ORMs, DSLs, and on and on. All of that remains true for enterprise today as well. And for the record, Gradle doesn't really check any of the marks you just listed, only DSL if you are squinting a little. Gradle is basically a application to run generic groovy code. There are literally no limits to what you can do, as you've got a full JVM to play with.

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 ago
  I'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 ago
    To 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.

surgical_fire 4y ago

> always hated it only slightly less than Maven. I used to dislike Maven until I was forced to work on a large codebase with Gradle. Now I think Maven is actually quite good.

MilStdJunkie 4y ago

"Captured by the tools" . . I am stealing that one! Whew, yeah, I stepped away from Gradle once I got the keys for our company's Jenkins instance. Jenkins was . . its own . . bag of rats . . but at least it was somewhat predictable. "Captured by the tools". You've described big label tech comms software from the last fifteen - nay, twenty - years. A . . frickin ECOSYSTEM . . an entire industry that outspends content creation several times over . . a vast panoply of ten thousand page specifications and eye-wateringly-expensive tooling . . all for making . . DOCUMENTS. For making documents. WHY DOES THIS EXIST. Actually, there's a reason. But it's not a functional reason or a technical reason; it's economics, culture, a whole maze of perverse incentives. Which is why it's so frustrating. I'm working on a presentation for exactly this, and it's been really cathartic.

doctor_eval 4y ago
This is exactly right. Why should my build tool require more study than the language I’m working in? Why do I need to learn a wholly language to build? In the same vein, why should the ORM be more complex than the database? Why should the application server be orders of magnitude more complex than my code? I mean - I do understand the reasons as given - I just don’t agree that the solutions are worth the sacrifices. I should not need a two week course to be good at some ancillary tool. This morning I started thinking about this thread and what I use today. I don’t even notice the build and dependency system in Go. It’s just there, and it works. Easy things are easy, hard things are possible, and performance is important.