I hate new DUB config format

Chris via Digitalmars-d digitalmars-d at puremagic.com
Tue Dec 1 02:14:08 PST 2015


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.


More information about the Digitalmars-d mailing list