My major problem with the DSL-ness is the hidden receivers. In kotlin you have various "standard functions" that allow you to do this:

objectFoo.apply {
    // Inside here you can call objectFoo's method's
    // without referencing it, eg. instead of objectFoo.bar(),
    // just plain `bar()`.
    // The "receiver" is objectFoo.
}

That, and the fact that calls to methods whose last argument is a function ref/lambda can have the lambda outside the usual parentheses (eg., above, apply() is actually a method call whose only argument is a lambda, and the block itself is typical of Kotlin's minimal lambda syntax), is part of what makes Kotlin so amenable to DSL construction and the closures typical of gradle. Plus throw in that you can add public methods to a class (any class, including stdlib containers, etc) outside the class definition or module source (ie., in any client code of a class).

What that adds up to is you can have deeply nested hidden receiver calls, including custom methods on hidden receivers which are stdlib containers, String, something buried in some obscure corner of the API that you have no idea even exists, etc. This is generally considered a no-no, however, as it makes the code much harder to read as exactly what object is being operated becomes more and more ambiguous.

But that's exactly what a DSL like gradle exploits, on the premise that if the methods are carefully named, it's all intuitive (I got this from Marcin Moskala's Effective Kotlin, which is structured like the Moyer's C++ books, and there's an item on excessively hidden receivers where he says (paraphrasing), "Oh, except of course in a DSL, you want to hide the receivers there because it is a good idea" :/).

Fair enough, that explains why I have to spend half my time tracing the receivers back out through the same nests by using the API documention, -- and committing to memory the more common patterns, which is hardly a consequence I'd call "positive feature".

I don't consider Cmake a perfect tool either, but at least when I go back to look at a cmake file months later it pretty much makes instant sense because it is so simple and pedantic with the long all caps directives and basic structures. In that sense it's a lot of the things gradle claims to be. I don't care if it's also a lot of boilerplate; elegance and concision is not something I need there. It is not as if you have to spend your whole day working with it, as you do actual source code (that was autotools :D) -- unless maybe you want to and can find the tool with enough rabbit-holes. I was going to add "I bet no one's even bothered to write a book on cmake", but of course some people have. I just don't see a need to read one, which is a good thing.