41–50 of 78 posts
JSON just works, everywhere, all the time. Sometimes I'll use SQLite if there is a particular need.
Can you show an example of how you use SQLite for _config_ files?
Earlier quoted context omitted.
It's readable, it's easy, it gets the job done. I don't think that's necessarily lazy, it's just efficient
> It's readable, it's easy That's what I am saying about my ruby codes as well. Still my boss wanted proper commit messages
TOML is a better format for configuration files IMO, if not for many reasons, primarily because TOML accepts comments. However, one annoying thing for TOML was the lack of schema, and the reliance on JSON Schema for that. Which I decided to tackle years ago when I started the TOML Schema project. In the past few months I leveraged code agents to take to the finish line and got something compelling: tomlschema.org
Reading and writing json is so much easier than reading or writing toml imo
I think this is the real "why do so many tools have JSON config files": because it's just a literal notation, for basic data structures, that looks a lot like what many programming languages natively do, what their data structures natively are. The answer to the post is: it's mechanistic sympathy.
For humans, I do find TOML to be a lot easier to manage. Even if you have a really good editor that takes care of all the quoting/nesting/comma concerns for you, even if you have jsonc or json5 with comments, it's still not as easy/friendly as a big flat file with sections in it.
> A lot of tech folks resist documentation because they think it provides them with job security. No, we're just lazy.
It's readable, it's easy, it gets the job done. I don't think that's necessarily lazy, it's just efficient
I wish everyone would embrace Amazon's Ion format. Of the data serialization formats it seems the most reasonable with the exception that it can encode S-expressions (so like having data serialization within your data serialization), so it is a bit excessive. https://en.wikipedia.org/wiki/Ion_(serialization_format)
Shame.
JSON is obviously a poor choice. It's job is to interchange data, produced and parsed by computers. ESR had the idea of writing configuration in English. It didn't gain traction at the time, but we have LLMs now. It might be a good idea to revisit the idea of accepting plain english. The LLM output could then be any format that's easy and unambiguous to parse.
because JSON is in the following sense "universal": every format/structure that has numbers, strings, booleans, null/none, finite lists of items, and string-indexed records of items already contains JSON and that's pretty much the barebones you need for a configuration language (of course you can argue about the syntax)
Lack of comments is pretty big though for a human editable config .
> Why do so many tools have JSON config files‽ 1: Because JSON is a very easy serialization format to work with. I suspect these tools all have configuration classes / objects that are deserialized straight from the config file. 2: I suspect a lot of these tools are written in Javascript, and in Javascript JSON is very easy to work with.
That's the whole post. First I don't know why this is posted on HN. Second I don't see how "JSON config" and "writing things down" are the two opposite options.