3 ms·
Was YAML, CSON or some other format considered for config? JSON is not exactly human-friendly.
by ricardobeat 8y ago
Was YAML, CSON or some other format considered for config? JSON is not exactly human-friendly.
- richardwhiuk 8y agoToml would be the best choice IMO
- crdoconnor 8y agoTOML is syntactically noisy and about 50% more verbose.
- cyphar 8y agoI'm not sure how [general] foo = bar is 50% more verbose than { "general": { "foo": "bar" } } But also it's significantly more human-readable (and critically, it's much more human-writable).
- crdoconnor 8y agoIt starts to get more verbose when you have more keys and deeper indentation since the whole hierarchy is repeated for each key e.g. [general.foo.bar.bar]. JSON wasn't intended for maximal human readability/writability like CSON/YAML were. It was intended first and foremost as a simple data transmission format.
- richardwhiuk 8y agoLarge hierarchies are always difficult in plain text formats. I'd argue if you need the user programming the config to understand a large hierarchy then you've already got a problem.
- crdoconnor 8y agoBy large I mean two/three levels and above. Nothing's perfect but YAML does that fairly well (e.g. ansible playbooks) TOML handles anything three levels or above in a less readable way than indented JSON (which doesn't even prioritize readability). It looks find provided you're only dealing with tiny ultra simple config files.
- richardwhiuk 8y ago[foo.blah.bee] hi = 4 seems readable enough.
- thechao 8y agoGRON and KVIN are better because: (1) I wrote KVIN as a long term joke to give my boss a stroke; and, (2) I like GRON’s author’s style. KVIN: https://github.com/jaroslov/kvin https://github.com/jaroslov/kvin GRON: I can’t find the spec; sorry.
- ajmmertens 8y agoYes, other formats were considered. There is some irony here, as I've been a vocal critic of JSON in the past (https://www.linkedin.com/pulse/may-time-stop-using-json-sander-mertens/ https://www.linkedin.com/pulse/may-time-stop-using-json-sand...). I ultimately went with JSON because it's ubiquitous, it has been used for similar purposes (NPM) and it has a great parser (parson) that was easy to embed without adding more dependencies to bake. Time will tell whether JSON scales, but so far it has held up pretty well. Bake has been used by small & big organizations, while building large numbers of packages simultaneously (150+). The most complex bake project.json I've seen was still far less verbose than the average CMake file (using CMake as a benchmark since it has been widely adopted).