Live data from Hacker News

Why do so many tools have JSON config files?

textlog.cc

21–30 of 78 posts

Re: Why do so many tools have JSON config files?

#21

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

I find TOML is nowhere near as good as YAML. I'd even rather use jsonc.

Yeah, I just use JSON5, it solves all the issues with normal json

Re: Why do so many tools have JSON config files?

#22
post #16
post #15

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 .

JSON still a very simple and useful format and being natively supported on the web and by javascript basically guarantees its universality. Native comments would be nice though. But to be fair even Douglas Crockford suggested using comments in JSON was fine as long as you stripped them out before parsing.

but Lua tables are even better.

Re: Why do so many tools have JSON config files?

#24

For our internal tooling we use something similar to a bash profile config file with name/value pairs separated by linebreaks. So, our configs look something like: env=staging db=0.0.0.0 #descriptive comment etc=true

ini file format is pretty much this

[section_name]

key=value

key=value

Re: Why do so many tools have JSON config files?

#26
post #10
post #5

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.

> The LLM output could then be any format that's easy and unambiguous to parse. Thats the problem isnt it? LLMs arent deterministic. Terrible for prod

Llms are absolutely deterministic if you want them to be.

Still a terrible idea for config

Re: Why do so many tools have JSON config files?

#27
post #10
post #5

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.

> The LLM output could then be any format that's easy and unambiguous to parse. Thats the problem isnt it? LLMs arent deterministic. Terrible for prod

I'm not sure why there's a problem before even trying.

Say for instance you have a program that keeps recipes. In your configuration file, there's settings such as metric/imperical units, allergies, diets, type of stove in your kitchen, and some theming (font, size, color...). You put them all in a file that you can parse, but aunt tillie messes up the formatting and the program breaks.

Instead of changing the config by hand, an LLM could supply the diff according to instructions in English. I really don't see why this would be "Terrible for prod". If the LLM screws up, you're simply back to square 1 and aunt tillie will call you just like she would before she had an LLM to fix her computer.

Re: Why do so many tools have JSON config files?

#30
post #23

> 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

> 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

Post reply on HN