On Tuesday, 1 December 2015 at 04:54:23 UTC, James Hofmann wrote:
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.
Yes, _all_ configuration file formats become a mess once you do
non-trivial stuff. However, for what you describe above, you
shouldn't have users edit JSON directly. If you deal with UI
stuff, have hundreds and thousands of people working on it,
people who are non-technical, you should use automated WYSIWYG
tools like Glade. Even a technical person might have difficulties
making non-trivial changes to huge configuration files manually.
[snip]
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...
Ain't gonna happen. I don't think anyone is interested in making
DUB dependent on JS or any other 3rd party scripting language,
e.g. Lua (which I like) or Ruby. I suppose DUB will always rely
on home made D solutions, and it should.