3 ms·
This may be right for a big distributed open source project or something, but most things I work on are proprietary within companies, and in that case it's easy
by sanderjd 4y ago
This may be right for a big distributed open source project or something, but most things I work on are proprietary within companies, and in that case it's easy to just pick something better and standardize on that. My current company is pretty much standardized on yaml, which isn't my favorite, but it's fine and better than json and we don't argue about it much. Things get serialized to json pretty often, but most stuff that is checked in and intended to be human readable is not json. A different company could easily pick cue or whatever else and it would work just as well.
- twic 4y agoI think this is a neglected point. For application config, the scope over which standardisation pays off is smaller than for data. It can be company-sized. Or language-sized - if all Ruby library use YAML, that's great for Rubyists; if all Java apps use properties files, that's, believe it nor not, pretty great for Java programmers.
- kaba0 4y agoHuh, yaml is just all around the worst on any metric. I would much rather stick to xml even.
- sanderjd 4y agoLike I said, yaml isn't my favorite either, but this is silly hyperbole; xml is way harder for a human to read and write.