I’ve promised myself never to use gradle
I’ve promised myself never to use gradle
www.andreinc.net
I’ve promised myself never to use gradle
29 comments
-
-
Gradle is absolute rubbish, definitely the worst experience I've had with a build system. But Maven is also rubbish.
IMO a CLI should be the primary way of interacting with the build system (see e.g. Go, Rust, JS with NPM or Yarn, Python with Poetry) and manually editing the build file should be reserved for edge cases and extensions.
-
As someone who wants to use Kotlin or Scala, is there another way to get around these two? Coming from .NET or NPM I found both of these to be terrible.
-
The "default" build tool for Scala is sbt.
-
There is Mill https://github.com/com-lihaoyi/mill
Which offers a nicer experience than the default Scala build tool: https://www.scala-sbt.org/
I personally like sbt a lot, but I've been told mill is more approachable.
-
-
-
-
Maven has a high learning curve, but once learned it is incredibly simple to use.
That high bar is created by the tool configuration. You can change and hack everything, but you have to understand how Maven works to do so. This generally blocks people from doing really stupid things, because you have to learn how maven works to successfully modify it and in doing so you learn why you shouldn't.
This is the exact weakness of Gradle, the barrier for modification is far lower and the tool is far less rigid. So you get lots of people who are still learning implement all sorts of weird and terrible practice.
The end result is I can usually dust off someone elses old maven project and it will build immediately using "mvn clean install", about half the gradle projects I have been brought in on won't without reverse engineering effort because they have things hard coded all over them. A not small percentage are so mangled they can't be built without the dev who wrote it's machine.
Also you really shouldn't be tinkering with your build pipelines that much. Initial constraints determine the initial solution, then periodically you review them to improve. DevSecOps exists to speed development and ease support it isn't a goal in of itself
-
Boom roasted
-
🍿
-
-
29 comments
Serious question: Is “Directed Acyclical Graph” really an unknown term for people? The author harped on it pretty hard, but what it is…is pretty apparent, no? I mean, I’ve encountered the term often, but I don’t think I had any need to look it up…
I'm a computer engineer with more than a decade of development experience with embedded systems... I use C/C++/python everyday and "Directed Acyclical Graph" is never mentioned by name, no one in my experience says make me a DAG. Hell, I had to look it up when I read your comment and went "oh that's what those are called". I use em to show relationships between states or to descide a system that is best diagramed using a DAG. Do I or anyone I've talked to in my career call them DAG.. lol no.
I thought this was basic CS 101, part of DSA
Yeah, I'd be pretty wary of a dev who needed clarification on DAGs...
Agreed. Why would a person need to look it up when the name literally describes it. Directed? Means connections are in a single direction. Acyclic? A-cyclic = non-cyclical, doesn't have cycles. Graph is... well a graph.
Which part does the author think an average programmer should struggle with?
It's very well-known and common knowledge. It's certainly something that I will talk about without feeling the need to define terms or something. I would assume anyone unfamiliar with it either didn't pay attention in school or never went to school to begin with.
I'm guessing I didn't know what it is by name because I never went for a compsci degree so you're probably right
Programmer/devops here. Without looking it up, I don't know what a DAG is. However, I'm guessing if I saw one, I'd recognize it.
...looked it up...
Immediately a dependency chart comes to mind