Had to update some CSS on my site over the weekend, which led me to updating some LESS file. The template I use for the site
uses Grunt, which forced me to download the entire Internet via npm. And all I wanted to do was set a text-indent to 0.

DSL’s over Make

If you look at all the examples above, they are nothing but DSL’s over Make in your language of choice. In some cases not even that, but just some syntactic sugar.
They still focus on the same core concepts:

Primitives

Targets

Tasks

and still force us to transcribe the complexity of a build system in written form.

And with each new Build tool, all we do is just add yet another grammar to learn, another series of tools and plugins
to download, configure and install. And for what? Just to have a bit of a nicer syntax? Without for a moment thinking
of the legacy that we leave behind with all these new ‘inventions’? Of course, some languages and platforms might need technology-specific tasks, but is a new build tool and syntax all that necessary?

I think Gradle’s tagline is somewhat approriate to describe all these different build tools: ‘Automation Evolved’. Yes, we’ve evolved
because we’ve moved from tabs and lines, to XML and then to, well, hmm, tabs, lines and curly braces.

Make, no more.

If you’re setting out to make another build tool, think about what benefit you’re going to provide over the existing ones. Adding yet another
custom DSL and grammar isn’t going to really solve any problem.

I feel there is innovation possible in build automation. We have a vast amount of existing knowledge on how software is built and the needs required,
we have seen the benefits of using convention over configuration, we have created powerful analysis tools. Combining these things I feel there is potential
to create a build tool that focuses more on discoverability than it does on us having to explicitly declare what we want done.