I hate new DUB config format

[James Hofmann via Digitalmars-d]

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...