Hacker News Reader

Comment by bborud | Hacker News Reader

Flexibility is not something I want in a build system. I want predictability and simplicity. "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later.

That being said, "flexibility" is not special to Gradle. As long as there have been build systems there have been people who are too lazy to learn them and get "bright ideas". For instance I have no idea how many shellscript-infested build setups I've seen for C programs that could easily have been built using entirely standard Makefiles. If the author had bothered learning to use Makefiles.

View on HN

> Flexibility is not something I want in a build system. [...] "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later.

We're on opposite sides here. I can control my team wrt rope and what not. But it's very hard to wrangle a build system to perform some advanced task you need without flexibility. I'd way rather have problems with the build system users than the build system authors. One is more easily fixable.

I agree. With an inflexible build system we still end up with the nasty shell script but it's worse because it wraps the build system.

Maybe combine a generic non-language specific build system (some variant of Make without the C obsession?) as the outer wrapper around a very language-oriented and inflexible/opinionated build system?

> some variant of Make without the C obsession

Make doesn't have a C obsession (although the docs do), make works anywhere you have a dependency graph that can be expressed as a file timestamp. Here's an example compiling a c# project: http://flukus.github.io/rediscovering-make.html . It's much simpler than any .net build tool (and I've tried them all).

Either you have a very strange concept of simplicity or you never tried Fake.

That's one I haven't looked at much, but can you show me a fake script that does the equivalent of my example? That means a fully incremental build, generating version files, etc. Even things like the version file tend to turn out more complicated in most build systems because they come with a half assed reimplimentation of unix tools

From a quick look t looks like it's task based instead of output based as well, so an incremental build doesn't look simple. Correct me me if I'm wrong, but it looks like it's trying to be a better nant, not a better make.

I've experienced this myself in a number of different environments. But I'm still not satisfied with the results with the more flexible tooling, usually. I think it's because they commonly lack scaffolding that I want a majority of the time.

The older I get, the more I realize that the lisp DSL approach is probably best: provide a simple, declarative walled garden. If I want to change something for my project using the full language, let me, and may the PR reviewers determine my fate. Ruby also seems to adhere to this philosophy, although I don't have a lot of experience with it.

> may the PR reviewers determine my fate

Confused here. I can't really stop progress waiting on build system features. Extensibility is required like a programming language. Otherwise, you must stop using the build system or build wrappers around it or outside of it making your build even more bespoke than if you used a more flexible system.

That's my issue: missing build system capabilities leaves me writing console apps to make builds sane.

If I'm writing code anyways in MyLanguage to compensate for MyBuildScript, why aren't my build scripts written in MyLanguage?

> I'm still not satisfied with ... more flexible tooling ... they commonly lack scaffolding that I want a majority of the time.

I think this dichotomy, flexibility vs maintainability, reflects build complexity.

Not only do I think the same-language-DSL (a la LISP, as you pointed out), is the 'least bad' choice, I think if we raise our gaze a little the answer here is painfully obvious: how do we handle those issues everywhere else?

In other cases if you need to move files, call some sys commands, structure some data, and express some logic? What if you have to call a webservice with some throttling logic, where is your "build language"? Plop something in a DB? Not to mention that complex builds often have specialized command line apps called by their specialized build langauge.... why?

Complex logic we use programming languages for. Why sacrifice power, components, libraries, compiler-time-checking, and all the rest to use a lesser tool? Full language power, it's The Right Thing.

You're assuming that you're around when the team is building out said system. What if you have the misfortune of inheriting a system where there was plenty of rope to go around?

Still better than having to abandon the build system altogether because it can't do what I want (or work around it which is often worse than leveraging flexible environments in the first place).

At least in Maven, the answer here is simple: write your own plugin.

You can do whatever you want, but you're still operating within the confines of the build system so you've not lost the ability to see what's going on.

It's not all that common that I see an "advanced task" that actually belongs in the build, though -- more often I see people who have decided to fight against their tooling rather than working with it.

Perhaps you can control a team, but how many people do you think you can "control"? Could you control every developer in a division? A company? And how do you onboard new people if any past experience with build systems is worthless because they have to learn how you do your particular build?

And if you find yourself consistently not being able to build a piece of software with a relatively simple build process, perhaps you are trying to do too many weird things?

> "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later.

In my experience, it's not dumb but clever which you should worry about — those are the ones who'll spend two weeks making something completely unmaintainable after reading someone's post about how some esoteric mathematically pure style delivered a 7% performance increase on an edge case.

"Clever" is just a polite way of saying "dumb" :-)

It's a different concept — closer to the difference between intelligence and wisdom. Someone who is cleverer than they are wise can go a long way before recognizing that the approach they're taking isn't cost-effective, especially if it gives them some point to feel proud about doing something which (correctly or not) they feel most other people couldn't.

Lack of flexibility means that it will only work for xx% of projects (supply an arbitrary value for xx but other than 100, by definition).

Then what it means, is that 100-xx percent of projects are going to be screwed up.

Not everybody lives in a nice world when the project is a single web application with 4 microservices and a shared library maintanied by a team of 5.

Out of those xx% of projects, how many really need the flexibility? Based on the last 30 years or so of being a developer, I would be tempted to believe that it would be in the low single digits.

It is sometimes worth it to spend a little extra time as you set up the build process, and as you make decisions on how to organise things so they can conform to a build process other people will understand. Quite often "clever" builds on long-lived projects, or projects with many developers, have a higher cost in terms of effort than what you save on "clever" shortcuts.

Well, if you will allow such a guy to operate alone without any code review, then I'm sure you have much more serious problems in the code, than a build system.

Most complex build setups I've seen in the wild the last 5 years were made by teams that have mandatory code reviews of all code.

This isn't so much about review or not as it is about not establishing a culture where you always take the easy way out. It is tempting to think that "this will be solved through the magic of code reviews", but if you are in charge of several teams and you have to face the reality of projects living on for years with people joining and leaving the team. It is important to have empathy with developers and your future self.

Much build complexity and annoyance is due to people taking the easy way out, for instance, by scripting things that should either be adapted to make use of an existing build process, or develop a proper plugin that is documented and helps newcomers to the project understand what is going on.

If you make it easy to make ad-hoc solutions, people will build ad-hoc solutions.

Reply on news.ycombinator.com