I entirely agree. But i also don't know what the Gradle authors could have done instead. Writing build scripts in Java 1.6 (the latest version at the time Gradle was written) would have been a showstopper. Kotlin didn't exist. XML alone isn't expressive enough, so you would have needed some sort of Ant-like crummy language expressed in XML.
Buildr, which i think predated Gradle, used Ruby. I'm not sure Ruby is any better than Groovy here.
It's interesting because plenty of build systems exist written in Python but they don't get much used because Python itself is not really flexible or expressive enough for writing good DSLs - and build systems are just specialised enough that a good DSL is actually required to do them efficiently.
So we seem to be on a never-ending treadmill of wheel reinvention searching for the right compromise between these things.
> It's interesting because plenty of build systems exist written in Python but they don't get much used because Python itself is not really flexible or expressive enough for writing good DSLs - and build systems are just specialised enough that a good DSL is actually required to do them efficiently.
Scons is another example of Python as the config language. In fact most of the times you don't need a comlicated DSL, or any language at all. Look at Webpack, npm, Android Blueprint or Bazel which more or less is just JSON-flavor, or Rusts Cargo.toml which is just toml markup.
You can get very very far with just a list of files and some config properties, if there is something complicated needed in the configuration the markup can refer to an external script.
In fact not accidentally mixing the configuration step with the execution step, as Gradle often does, can be considered a feature.
Cargo isn't just TOML, it's TOML, plus a build.rs script, written in Rust, for everything you can't express in the TOML.
I agree that a lot of the time, you don't need Gradle's sophistication. But large, complex projects, in my experience, inevitably develop strange and unusual build needs. At that point, if your tool doesn't support them naturally, the complexity ends up going somewhere else - you have to write plugins, or standalone tools, or build script generators, or manage a lot of repetition in the build script, or multiply subprojects, etc, so you can do what you need to do.
> Cargo isn't just TOML, it's TOML, plus a build.rs script, written in Rust, for everything you can't express in the TOML.
Cargo is nice--until you have to coexist with something else that also wants to own the world of the build process.
And that build.rs script causes a LOT of heartburn when your needs get larger or you need repeatable builds.
I don't know what the right answer is, but cargo is exactly the kind of system you describe that you have to start working around when you have more sophisticated needs.
Buildr, which i think predated Gradle, used Ruby. I'm not sure Ruby is any better than Groovy here.
Perhaps Jython would have been a good choice.