3 ms·

This seems like it'd be easy to shoot yourself in the foot with, especially with the duplicate keys and concatenation behaviour. YAML is also a JSON superset an

This seems like it'd be easy to shoot yourself in the foot with, especially with the duplicate keys and concatenation behaviour. YAML is also a JSON superset and is significantly easier for humans to parse. This seems to make many of the same mistakes that POSIX shell syntax makes.

vesinisa 9y ago
This might be an unpopular opinion, but I find it terrifying that people keep repeating the same mistakes. Back in the 90s everyone thought that XML would become the one and only configuration file format. Instead, it became an epitome of over-engineered enterprise software. Now, people are moving to JSON as a serialization format. It's a lighter-weight and usually sufficient distant cousin of XML, but I still wouldn't like to write my config files in it. The misconception is what might work as a human-readable serialization format is usually tedious as a human-editable configuration format. Unless your app accepts configuration files as untrusted input, it is really not that hard to write a custom key-value -type parser. Think OpenSSH or Samba config files - I find them well-suited for their respective jobs, as they achieve the required level of expression with minimal necessary complexity.
- viraptor 9y ago
  > it is really not that hard to write a custom key-value -type parser It's not. But then you want to set up that config automatically. So you template them. Then you discover they have slight differences in what they accept and how they handle unknown/repeated values. Then you discover they have different escaping rules. Then that one needs non-latin characters quoted. etc. etc. It's not easy to write parser for each one of them. But if you're installing a full server with 10 different config files, you end up with 10 templates which you just hope never run into any edge case of a particular format. And hope that the next service will just use JSON. Or YAML. Or whatever standardised.
- skybrian 9y ago
  Sadly, few people can design a text file format that handles escape sequences properly. I asked this as an interview question for a while, and I've also seen people who should know better get it wrong in production. It's a really good thing that these days, people use JSON most of the time.
paulddraper 9y ago
> This seems to make many of the same mistakes that POSIX shell syntax makes. How's that? > easy to shoot yourself in the foot with, especially with the duplicate keys and concatenation behaviour Maybe, but that is the entire point of HOCON: to compose configuration. E.g. you have a defaults.conf file, but then you have a production.json files that includes defaults.conf and overwrites some of the value. Or, at the end of your config file, you include "local.conf" and then you can put temporary local changes in a (gitignored) local.conf file.

vesinisa 9y ago

This might be an unpopular opinion, but I find it terrifying that people keep repeating the same mistakes. Back in the 90s everyone thought that XML would become the one and only configuration file format. Instead, it became an epitome of over-engineered enterprise software. Now, people are moving to JSON as a serialization format. It's a lighter-weight and usually sufficient distant cousin of XML, but I still wouldn't like to write my config files in it. The misconception is what might work as a human-readable serialization format is usually tedious as a human-editable configuration format. Unless your app accepts configuration files as untrusted input, it is really not that hard to write a custom key-value -type parser. Think OpenSSH or Samba config files - I find them well-suited for their respective jobs, as they achieve the required level of expression with minimal necessary complexity.

viraptor 9y ago
> it is really not that hard to write a custom key-value -type parser It's not. But then you want to set up that config automatically. So you template them. Then you discover they have slight differences in what they accept and how they handle unknown/repeated values. Then you discover they have different escaping rules. Then that one needs non-latin characters quoted. etc. etc. It's not easy to write parser for each one of them. But if you're installing a full server with 10 different config files, you end up with 10 templates which you just hope never run into any edge case of a particular format. And hope that the next service will just use JSON. Or YAML. Or whatever standardised.
skybrian 9y ago
Sadly, few people can design a text file format that handles escape sequences properly. I asked this as an interview question for a while, and I've also seen people who should know better get it wrong in production. It's a really good thing that these days, people use JSON most of the time.

paulddraper 9y ago

> This seems to make many of the same mistakes that POSIX shell syntax makes. How's that? > easy to shoot yourself in the foot with, especially with the duplicate keys and concatenation behaviour Maybe, but that is the entire point of HOCON: to compose configuration. E.g. you have a defaults.conf file, but then you have a production.json files that includes defaults.conf and overwrites some of the value. Or, at the end of your config file, you include "local.conf" and then you can put temporary local changes in a (gitignored) local.conf file.