I'm usally confronted at YAML when I setup gameservers of some indie games (I'm looking at you Empyrion) and I find it extremely painful to handle.
When you have sevral configuration files where you have to change/tweak data I always end up pulling my hairs why stuff isn't working because of an extra space lying anywhere in the file.
Please don't use YAML for anything that has to be edited by a human
INI, XML, JSON are all formats that are more forgivable regarding that (oh and always trim anything you parse. The more you do to help against accidental input, the less admins you'll have ;)
It's weird how languages like YAML, XML and JSON are very much designed for communication between machines, but are still the default choice for human input. Actual programming languages - designed for use by people - are rarely considered for high level configuration.
I have actually seen something similar to this happen:
1. We just need a few configuration options. Let's add an XML configuration file.
2. Keeping all the configuration files in sync for different environments is a lot of work and really error-prone. Let's generate all the configuration files. What about an XML meta-configuration file?
3. Some things are different between environments. We need conditionals in our XML meta-configuration language.
4. There is a lot of repetitive configuration. It would be more maintainable if we had loops, variables, integers, string interpolation, functions, ... in our XML meta-configuration language.
Great, now we invented our own awful programming language that lacks any tooling, documentation or libraries and isn't compatible with anything else.
>It's weird how languages like YAML, XML and JSON are very much designed for communication between machines, but are still the default choice for human input. Actual programming languages - designed for use by people - are rarely considered for high level configuration.
What are you talking about? YAML, XML (particularly HTML) and JSON were always intended to be written by and understood by human beings, no less so than any "programming language." All of these were designed to be "used by people" and machines.
>Actual programming languages - designed for use by people - are rarely considered for high level configuration.
And the rest of your comment illustrates why. What you have when you use a programming language for "high level configuration" isn't configuration. Configuration should describe constant state, not operate on or transform mutable state. What you have, then, is just more application layer, on top of your application.
Which you don't have with JSON. Or INI. And you do still kind of have with YAML, and definitely can with XML, but that's why a lot of people don't like YAML or XML when it gets too complex.
What it looks like your example shows is dumping unnecessary complexity into configuration in order to maintain "simplicity" in the application. You would have the exact same problem using a high level programming language, it would just be potentially infinitely worse with the explosion of complexity and feature creep that comes with it.
When you have sevral configuration files where you have to change/tweak data I always end up pulling my hairs why stuff isn't working because of an extra space lying anywhere in the file.
Please don't use YAML for anything that has to be edited by a human
INI, XML, JSON are all formats that are more forgivable regarding that (oh and always trim anything you parse. The more you do to help against accidental input, the less admins you'll have ;)