undefined | Better HN

0 pointsZenPsycho10y ago0 comments

I think the problem it is solving is that JSON is designed and best used as a data exchange format, but it also gets used for configuration files, which it does okay with but is not really so good. INI files don't have a clear standard. YAML is too complicated, and using turing complete javascript for configuration seems like you've just gone too far.

we just need JSON, but with a couple things fixed up to make it nicer to use for configuration files.

0 comments

5 comments · 2 top-level

kbenson10y ago· 3 in thread

> we just need JSON, but with a couple things fixed up to make it nicer to use for configuration files.

Using JSON for configuration is just the whole situation of using XML for data exchange redux. One of the major points for JSON over XML for data exchange was that it was so much better because it was optimized for data, not markup. Why are we ignoring this argument now that JSON is on the other side? JSON is used for configuration because it's ubiquitous, not because it fits the problem domain well. Let's just choose a more appropriate format.

Choosing the most common set of rules for INI files (what is proposed by Wikipedia[1] is probably sufficient) would serve us MUCH better than coaxing a data interchange format into that role.

1: https://en.wikipedia.org/wiki/INI_file

lomnakkus10y ago

If you're using a strongly typed language, XML even has one (IMO) massive advantage over JSON: You can use XSD to define a schema declaratively. This means you get

(1) lots of general tooling support, in particular you get at least decent editor support for your config file, and

(2) you can autogenerate the code needed to read your configuration into structured data without having to do any unnecessary duplication of "key names" (tags) as you have to with e.g. INI or JSON. You also get the data sturctures themselves for "free" (based on the XSD).

Alright, it's not the end of the world to not have these things, but they're both very nice to have.

ZenPsychoOP10y ago

have you seen http://json-schema.org ?

1 more reply

ZenPsychoOP10y ago

well basically virtually anything other than JSON that's actually designed to be configuration would be better for configuration. There's dozens of them. that is the problem: JSON parsers and generators are ubiquitous in the way that no single configuration format is. Right now, I can just use json in any language and get data between any language and any other language. If I use it for config I get the advantage of even being able to config across multiple languages that might be getting used in a single system if I have to. No proper configuration format has that level of mindshare and interoperation.

thenonameguy10y ago

Something like edn[1] perhaps? Worked really well in my projects.

[1]: https://github.com/edn-format/edn

j / k navigate · click thread line to collapse

0 comments

5 comments · 2 top-level

kbenson10y ago· 3 in thread

> we just need JSON, but with a couple things fixed up to make it nicer to use for configuration files.

Choosing the most common set of rules for INI files (what is proposed by Wikipedia[1] is probably sufficient) would serve us MUCH better than coaxing a data interchange format into that role.

1: https://en.wikipedia.org/wiki/INI_file

lomnakkus10y ago

If you're using a strongly typed language, XML even has one (IMO) massive advantage over JSON: You can use XSD to define a schema declaratively. This means you get

(1) lots of general tooling support, in particular you get at least decent editor support for your config file, and

Alright, it's not the end of the world to not have these things, but they're both very nice to have.

ZenPsychoOP10y ago

have you seen http://json-schema.org ?

1 more reply

ZenPsychoOP10y ago

thenonameguy10y ago

Something like edn[1] perhaps? Worked really well in my projects.

[1]: https://github.com/edn-format/edn

j / k navigate · click thread line to collapse