Am 16.09.2016 um 10:24 schrieb Chris Smith:
With this in mind, a lot of the statements about these various languages are not entirely convincing. That it's a superset of JSON? It's not clear why this matters.
It does matter for people who already know JSON: They can skip over the config file syntax and dive right into the semantics. Given that a substantial fraction of programmers knows JSON, using that syntax would create a lower entry barrier. The same argument can be made for YAML. This argument cannot be made for TOML at this time, maybe never if TOML's limitations prevent widespread adoption.
A psychological impression of complexity? Just not anything I've seen evidence of. Indeed, aside from the rather painful many-years-long migration, the *cost* (though certainly not a prohibitive one) of moving to something like YAML or TOML is that they have a bit louder syntax, that demands more attention and feels more complex.
YAML's complexity is partly because it tries to cover everything, partly because it is pushing hard to be both human-readable and machine-readable. It's pretty good at this actually, though I guess 20/20 hindsight could lead to improvements - but not enough to make a new YAML version worth the effort.
There is one substantial disadvantage I'd point out to the Cabal file format as it stands, and that's that it's pretty non-obvious how to parse it, so we will always struggle to interact with it from automated tools, unless those tools are also written in Haskell and can use the Cabal library. That's a real concern; pragmatic large-scale build environments are not tied to specific languages, and include a variety of ad-hoc third-party tooling that needs to be integrated, and Cabal remains opaque to them. But that doesn't seem to be what's motivating this conversation.
That's implicit in the "it would be nice to have a standard format" argument, even if it hasn't been explicitly voiced yet.