Tuesday, July 2, 2013

Gradle thinks overloading is so cool

In Java, it all started with Ant. Then came Maven, but strangely, somehow I always ended up working on projects that didn't use it. And finally we have Gradle.

I am by no means any expert in Java build tools, so maybe there are some additional ones out there, but I'm pretty sure these are the 3 crucial ones. Anyway, me and my coworkers heard many praises about Gradle, so after using Ant (+Ivy) for many years, we picked it as our next build tool.

We've been using it for some time throughout the company, and although I haven't been primarily dedicated to it, every now and then, I had to occasionally change something in the scripts. Gradle is definitely big improvement over Ant which is too low-level and doesn't provide any of higher-level concepts so frequently found in (Java) development.

But, I immediately noticed something which bothered me...

I dunno if this is somewhat caused by Groovy language itself, which I never studied, but Gradle has overly large number of ways to do the same stuff. Naive person would think that this is good thing, because if you have some objections on one way of doing things, you can always pick another. Really my friend, is that so?

The point is to expose the smallest possible number of paths to a goal, because a developer cannot remember and master too many of them, and in the same time, to give maximum possible power through them. Some ingenuity is required to develop such technology of course, and none is perfect, so I don't mind any compromises, but I noticed that people like to talk often only about large number of features, like there isn't any drawback in that.

One could say - well, nobody forces you to remember every way of doing some thing. That's simply not true. Over any proper span of time, you will have to work on your coworker's code sooner or later, and if he has chosen some other style, you are forced to learn his way. Eventually, you will have to learn most of approaches to feel comfortable when working with the tool. Its not just about your coworkers - when we learn new stuff, or stumble upon some problem, the preferred way of doing things is to Google the problem and copy-paste some solution from the web. And of course, there is no guarantee that this piece of code has picked your way of doing things.