Hacker News new | past | comments | ask | show | jobs | submit login

I don't agree. Configuration files tell a program what to do. You want expressive power there. Telling a program what to do merely through values only makes things more indirect.

To give an example: you can get into the situation that some configuration values are only valid when configuration value X is Y, and otherwise other configuration values are valid. What better way to model this than through an if-statement in a programming language? This makes it immediately apparent which settings have effect.

I am involuntarily howling internally in anguish, and if the feeling could speak, it would be screaming "parse, don't validate" (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...).

If some config values are valid when X is true, and other config values are valid when X is false, then use a different schema for the two cases. This is what discriminated unions are for: for representing conditionals statically, inspectably, serialisably!

If some config values are valid when X is 0.339, and some are valid when X is 0.340, and some are valid when X is 0.341, and so on, then… I don't know how to help, and maybe I must just avert my eyes in shame as I implement the dynamic logic. (But in that case it seems a bit odd to say you're "telling the program what to do" with this configuration; I'd say you're bolting on a little extra program at the start.)

Sometimes “valid” doesn’t mean “illegal to have in a configuration file”, it just means that “in this specific case, the configuration should have a certain value”. For example, on my Mac I should prefix my commands with “g” if I want to access GNU tools, while on most Linux systems I don’t need to do this. Trying to run gsed on Ubuntu would be “invalid” in this case but a parser can’t help me here.

Yes it can: if your config file is more declarative than simply "lists of command lines". The program can determine what is true of its environment, and can construct command lines appropriately given the data about intended outcome that is stored in the configuration file.

I can’t change the program.

I once wrote yet another JS static website generator. It incorporated exactly what you mention: powerful configuration. It was pretty awesome, each website could write their own extension functions and really enhance the way the generated HTML was formed.

In 8 months I couldn't understand head nor tails of the configuration, where and when certain functions were used, etc.

It was (and is) my greatest disaster in writing a static website generator. (And I'd written 3 pretty decent ones before that). FWIW here's the code: https://github.com/ergo-cms

I'm not sure why choosing a configuration file format like ini or yaml prevent configuration validation. This logic can be expressed within the program itself: parse the file, and validate inside the program that the configuration is consistent.

Also putting the validation logic directly inside the configuration file is not a good idea in my opinion for two main reasons:

* the validation logic is then "external" to the program and can be overridden (with potential catastrophic effects) by the operator installing the program.

* Configuration validation logic can be quite complex, and having it inside the configuration file would clutter it too much in many cases.

I tend to see configuration files as an API/Interface (maybe because I'm an SRE), and as any interface, I want it clearly defined, with known boundaries and as explicit as possible. For these reasons I'm not a big fan of using a fully fledge programing language as configuration.

> Configuration files tell a program what to do

The source code tells a program what to do.

Configuration tells the program about its environment.

it depends on the application. For things like build systems, ci systems, infrastructure as code, and even things like reverse proxies and webservers, the config definitely DOES tell the program what to do. And in those cases I think a full programming language makes more sense. For programs like say, a word processor, where the config really is just the environment, and is suffiently simple, something like yaml is sufficient. but please use a format that supports comments if it will be read or written by humans.

I should know more about those uses cases to say anything about it.

My hunch is that it would be good with a different term than "config" for those things.

> Configuration files tell a program what to do.

Configuration may be an overloaded term, but in my terminology telling machinery what to do is the function of the code. Configuration gives users, who in general have neither interest nor skill to follow the algorithm paths, some high level options to control the program execution. Thus config files need to be small, clean and well commented. Just my 2c.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact