Hacker News Reader

Comment by selfmodruntime | Hacker News Reader

I am baffled that we as an industry landed on the concept of „code over configuration“, then went on to choose text based formats like yaml or json and consider it perfectly normal to write these by hand? Or even worse, we use bastardized in-file template strings to generate hopefully valid YAML in the end.

What‘s wrong with configuring our platforms with a real, perfectly working programming language? I think the author had a great point with the schema being disconnected from the configuration file, but he missed the big picture with JSX: JavaScript (or TypeScript) can be perfectly used to emit JSON. JS tooling works with .config.js files.

Why must I experience the living hell of helm charts and kubernetes configuration file templates, when I could just emit my config with my favorite programming language?

View on HN

> What‘s wrong with configuring our platforms with a real, perfectly working programming language?

Python's "you must execute arbitrary code to find out a packages dependencies", and the hell that makes working with their packaging ecosystem as a whole, is what's wrong with using a general purpose programming language for configuration (not that I'm a fan of YAML either)

To be fair, that’s because Python packaging was “invented”/formalised a long time ago, before it was generally considered a bad idea. And a lot of the rationale for this was because you wanted to select specific dependencies for specific platforms, and there wasn’t a proper way to do this.

But now, almost all packages are specified using plain text files. You still need to execute code to compile a sdist that has native code, but that’s a separate thing.

One would think that this scar is bad enough that python would address it.

Candidly I think python is going to be forever stunted after the python 2 to python 3 multi year fiasco.

I've worked with frameworks that required users to use a programming language to specify configuration. It was a nightmare to debug, especially if the application would instantiate many different things in response to such completely free configurations.

Every user reporting a problem incurs in a lot of cognitive load for you because the user has the freedom to go crazy with a real programming language.. or not but it's just different enough from the previous bug report that you can't generalize your troubleshooting.

I think our best hope right now is to have jsonnet be more widely adopted.

This is not a problem if the configuration script just emits a valid JSON object according to your defined schema. On bug reports, your users send the generated config and you don‘t deal with the specifics.

> don‘t deal with the specifics.

Good luck with that. You'll be teaching your users (especially the paying ones) how to use the language.

Because that solution would be just your favourite language and the next person would create documentation using your least favourite language, next person would optimise the internals to be easier to work with their choice, next person would answer on SO using their choice, etc.

Nobody stops you from creating the configs right now using your own serialiser, but having a common understanding of what's being read by the app and mostly talking about that format helps the ecosystem.

This pattern keeps repeating because the creators of an app think they need a configuration language (which some users do) and then when eventually other users end up needing an API or some feature the config language doesnt have. They both dont exist so they hack it with templating.

It's often quite hard to know what kind of problems need an API and what kind of problems need configuration. It's sometimes only obvious in retrospect - the same point when you also get held back from changing things by backwards compatibility and culture.

The reverse problem (no configuration, only turing complete code) carries its own set of problems and can be just as infuriating. Getting the balance just right is hard and often only clear in retrospect.

Kubernetes really should have done something about the templating horrors by now though.

You will love Projen and AWS CDK if you don’t know these already!

What will those programming languages output?

JSON

Reply on news.ycombinator.com