Hacker News Reader

Comment by lolinder | Hacker News Reader

Honestly, all of these arguments feel pretty subjective to me.

This is the major problem with most comparisons of config file formats: the actual semantic domain of a config file format is extremely limited, which means the main thing left to disagree over is syntax, which is highly subjective and extremely difficult to get people to agree on.

Add too many syntactic features and a lot of people will disavow you for being too complicated. Add too few and you'll be missing someone's pet feature. Make white space significant and you'll frustrate people. Require extra characters to delineate and you'll frustrate another group.

It's worth noting that this article is primarily talking about TOML in the context of the Python ecosystem, and I think that's a healthier way to talk about config file formats: How well suited are their syntactic choices to the community they're targeting?

View on HN

Yup. I've personally used both YAML and TOML for configurations, much more the latter recently and can see pros and cons for both.

> How well suited are their syntactic choices to the community they're targeting?

Also, "best" practices. One could reduce the pain of the other, but by no means is the right solution to a deeper problem at hand. For example, if one has very deep and complex nesting for configs, TOML "may be a lot nicer" compared to YAML, but that doesn't mean using TOML will make all the config parsing problems go away. It just mask away code smell. Maybe time to check if they're overcomplicating configurations in general.

> This is the major problem with most comparisons of config file formats: the actual semantic domain of a config file format is extremely limited [ ... ]

So, why not use Scheme ?

Scheme lacks most syntactic affordances that imply semantics. Even if some of those implications are dead wrong, they're still useful.

Personally I think the right answer for configuration files is to define them in terms of a generic object model. A program could even support multiple formats (TOML+JSON+YAML). If a user dislikes all the supported formats or the file is generated with something like NixOS, it can be handled with straightforward conversion.

> A program could even support multiple formats

I invite you to check out Symfony where you configure your app using yaml, attributes in code, code itself, or a mix of all the above.

You will cry.

Point taken, but it would seem the problem there is probably due to the arbitrary placed mixins? My proposal was more for a single configuration object, just in whatever actual syntax you (or your team) prefers. If someome runs away with that and writes json that includes yaml that includes python that generates configuration from what it found on the filesystem, responsibility for that needless complexity rests squarely on the shoulders of the new programmer.

Having syntactic affordances for every nuance of semantics is what led to the current state of zoo. What is wrong with having trivial syntax and distinguishing semantics by labeling parts of the syntax tree with symbols?

Specifically with scheme, I believe the main problem is the symbols lack any distinction to know the difference between a function call and a syntactic form.

(Don't shoot the messenger, I've done my fair share of scheme. I've also done a lot of thinking about why some people are so turned off from the syntax, and it's certainly not that the opening parenthesis is in a slightly different place on the prefix function calls)

Some do, using s-expr as config files is pretty common in the ocaml ecosystem (ie dune).

>Make white space significant and you'll frustrate people.

Or worse: make whitespace significant and strike a blow in the eternal tabs vs. spaces holy war at the same time, like YAML.

...or more famously, Makefiles

I would disagree

It's kinda crazy we have 2 kinds of whitespace.

Even the customizability argument makes less sense now, IDEs could just change the width of leading spaces, I'm not sure why they don't.

Isn’t the whole premise behind this article that, coming from Python where indentation is program structure, that TOML confuses the reader with syntax foreign to the reader?

Like a C++ developer crying foul because inheritance doesn’t exist in YAML.

Make that C++ developer's day by pointing out that YAML does support inheritance: https://dmitryrck.com/how-to-use-inheritance-in-yaml-files/

Pfffffft, you know very well C++ developers don’t write yaml. They write m4.

SciTE uses lua for configuration.

Thankfully, YAML supports SFINAE

Reply on news.ycombinator.com