Although I admit to coming in late to a big bikeshed-fest, I have
some opinions on configuration file formats from having seen
younger, non-technical end users try to configure their own game
servers. The support cost of misconfiguration due to syntax error
is enormous. Gob-stoppingly huge. It is day after day of
Q: hey it's broke fix it
A: you forgot to add a double quote in your config file
And so when the file format is pressed into the role of primary
UI, and is touched directly by hundreds or thousands of people,
who want to write things that are more than a few trivial lines,
relying only on JSON, which biases towards parser and programmer
friendliness, not towards forgiving syntax, is not the right
trade-off for total human effort and the stress levels of project
maintainers. Those files are source code and need the additional
care and forgiving structure of a source code language. If you
want externally-generated configurations, then JSON is the right
move, but it is not a complete design - it's passing the buck to
users.
For similar reasons there are a lot of interfaces and formats for
writing documents and nobody is entirely happy with any of them.
It's easy to write simple things in Markdown variants, but
complex material pushes against the feature boundaries. You can
do pretty much everything with DocBook or TeX, but they're a
chore. Word processing tools can smooth out the problem of
discovering features, but again restrict your control and emit
weird markup in the process. The happy medium workflow tends to
involve writing in a "light" format and then transferring content
to the "heavy" one to merge it and add finishing touches.
A year or two ago I spent a lot of time thinking about
source-vs-serialization trade-offs. When you can get
bi-directional serialization and ensure that pretty-printed
output looks like the original input, you lose some freedom on
the end of the user being allowed to make mistakes or change up
their style partway through. Sometimes you want that, and
sometimes you don't, and it really does depend on the context
you're putting that format into.
If you look at Lisp family languages, for example, they take an
extreme posture on bi-di behavior in that "code is data and data
is code", but that also means that their ecosystem is defined
around having s-expression-friendly editors and a coding style
that biases a bit more towards using powerful language extension
tools. And it's another valid way to go with configuration
formats, of course. It would make sense to jump all the way over
to a script interpreter if, as got mentioned earlier in this
thread, SDL were to start being extended to do "programming-like"
things.
FWIW, I'm tempted to take the side of "make JS the default,
compile existing SDL and JSON to JS when run, add compilers for
TOML or YAML if there's demand". If you make code your lowest
common denominator, nothing else matters, and JS is the de-facto
lowest common denominator of code, today. Someone presented with
a config whose syntax they don't know can tell Dub to port it to
JS and edit that instead, and so over time all configs end up
being a blob of JS code, in the same way that the "light"/"heavy"
markup situation is resolved by gradually converting everything
into the heavy format even if it didn't start there. That is OK.
Dub might run a bit slower, and there are some security issues
raised from it, but the world is unlikely to blow up because
someone wrote "clever" JS in their Dub config.
Also, people will see the option of coding JS and go, "Now I can
write a build system on top of Dub, and it can use my own config
format, way better than SDL or YAML or TOML! Everyone's gonna
love this!" The D and Dub maintainers smile innocently and say
nothing...
