Any sufficiently complicated configuration language contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. [1]<p>[1] A variation of <a href="https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule" rel="nofollow">https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule</a>
Yet another tool to parse one large string into a map of smaller strings. Trouble with configuration files is rarely caused by insufficient syntax features, but insufficient schema validation seems to be a consistent source of wtf-moments: a mistyped key here, a duplicate key there, that's what is stealing our time (duplicate key: first definition wins? last definition wins? both get concatenated? doesn't matter, if i was aware of having two of them i would have fixed it in a second).<p>What i want from a configuration helper library is nothing less than an internal DSL for specifying the typed structure of allowed/expected keys, together with their default values and a short "what is this" description available at runtime. This would be enough to generate nice empty configuration templates and create warnings for unexpected keys (be it from typos or from unexpected duplicates).<p>Fancy syntax features for the configuration files themselves would be only secondary niceties. And candidates for "stupid" preprocessors ("stupid" in that they would not have to know about the appllicaton's configuration schema).
Currently, I prefer [toml](<a href="https://github.com/toml-lang/toml" rel="nofollow">https://github.com/toml-lang/toml</a>) for configuration. Both languages can be exported to JSON.
I am, I'm sorry to say, unconvinced. I'm not keen on 'magic' behaviours like auto-converting of values to arrays -- while the behaviour of the document may be well specified globally, it's nice to be able to see what something's going to do based on immediate (or even no) context.<p>What I'm very much liking at the moment is the way Dropwizard uses Jackson's YAML (and by extension, JSON) parsing for configuration -- your configuration file maps 1-1 to a class in your application, and Jackson is configured to fail if you're either missing a field that's not marked as optional or you've got extra fields in your YAML that don't map to anything. Type-safety FTW!<p>On the subject of wanting to refer to earlier bits of configuration: if you need to use one value as part of another, your configuration system might not be exposing the right level of detail. Of course, you might not be able to change that.
This has some good ideas, but it's very similar to HOCON. I think it's more worthwhile to focus on improving the HOCON spec rather than building yet another configuration json superset.<p><a href="https://github.com/typesafehub/config/blob/master/HOCON.md" rel="nofollow">https://github.com/typesafehub/config/blob/master/HOCON.md</a>
The "Automatic arrays creation" bit rather worries me - it strikes me that very often if you have non-unique keys, it's because you've made a mistake, so automatically converting that object into an array would probably result in misconfiguration.
Looks interesting, however the only reason JSON is generally used IMHO is because it's light and compatible. There is no reason to make the new language look like JS (a lame legacy language). It could look like YAML but still support JSON for legacy stuff.
The Typesafe Config is somewhat similar in the JVM world.<p><a href="https://github.com/typesafehub/config" rel="nofollow">https://github.com/typesafehub/config</a>