Hacker News new | ask | show | jobs
by gregmac 2024 days ago
> someone inevitably shouts "use the simplest tool for the job!"

I think one problem is that configuration needs start out simple and evolve to complex - as opposed to being obvious from the start you'll need dozens of discrete components to deploy. At that early stage, anything beyond a few lines of YAML seems like definite overkill.

Eventually, it becomes clear that it's very hard to maintain, but by then there's thousands of lines of hard-knocks battle-tested, working production config to try and basically recreate from scratch, without breaking anything.

Until you've gone through this process once (or maybe a couple times..) it's hard to see why you should make that initial leap to a much more complex, tools-required workflow. "But eventually, we will probably need..." is a tough sell against someone arguing to do the simplest thing.

1 comments

That’s where experience comes in. We should know that certain domains (e.g., Kubernetes configs) are going to get unruly fast and we oughtn’t waste time with YAML. I don’t think this will be a controversial opinion in a few years time.
Also; more generally: it makes sense to KISS, and the key risk here isn't somebody using yaml or json or whatever initially - even where experience shows that's insufficient, it's just not that costly either. The question is what to do when that becomes unwieldy. And I think it's pretty clear that kinda-sorta-programming that tries to incrementally extend stuff like static config languages - but only slightly - doesn't work well and is a bad idea. It's inconvenient; it results in many of the same issues as a full programming language, and it's often really inconsistent in its expressiveness - as in, for any given application thereof you're likely to run into limitations.

I think it's wise to try and skip as many of those intermediate stages as possible. Of course; that's not a clear-cut solution strategy either; because what's "as possible"? Exactly how high up the language chain do you need to go; conversely which language (and environment) features are too powerful, rendering the language difficult to contain?