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.
Removed by mod
I thought this was basic CS 101, part of DSA
Yeah, I’d be pretty wary of a dev who needed clarification on DAGs…
deleted by creator
They probably know what it is, but it’s a bad point if they’re trying to paint DAGs as esoteric CS stuff for the average programmer. I needed to use a topological sort for work coding 2 weeks ago, and any time you’re using a build system, even as simple as Make, you’re using DAGs. Acting like it’s a tough concept makes me wonder why I should accept the rest of the argument.
Can’t say I have a strong feeling about Gradle though 🤷♀️
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
It’s never too late to learn about them. They’re super common in practice so it’s very helpful to know about them. A lot of things are a DAG, like tree data structures and dependency graphs. Having no cycles in a directed graph has a lot of nice properties too, like allowing one to use efficient graph traversal algorithms, topological sorting, or its transitive closure. It’s come up multiple times in my career so it’s definitely worth knowing imo.
Removed by mod
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
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.
Removed by mod
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
Completely agree. I can jump into any maven project and understand it with ease. Gradle on the other hand requires deep understanding of the build file due to all the flexibility that it offers.
Removed by mod
Maven has unit and integration test phases and there are a multitude of plugins designed to hook into those phases but there are constraints by design.
Trying to hook everything into the build management system is a source of technical debt, your using a tool for something it wasn’t designed.
I would look at what makes sense within the build management system and what makes sense in a CI pipeline.
CI tools have different DSL and usually provide a means to manage environments. Certain integration and system level tests are best performed there.
For instance I keep system tests as a seperate managed project. The project can be executed from developer machines for local builds but I also create a small build pipeline to build the project, deploy it and run the system tests against it triggered by pull requests.
This is why I say the build management system doesn’t really change, because you should treat everything as descrete standalone components.
The Parent POM gets updates once every six months, the basic build verification CI pipeline only changes to the latest language release, etc…
Projects which try to embed gitflow into a pom or integrate CD into the gradle file are the unbuildable messes I get asked to fix.
Removed by mod
Boom roasted
🍿
