> Why do so many tools have JSON config files‽ Commenting why options have been set the way they have is just such a basic thing to want to do… Why do tech people have such an aversion to writing things down⁇<p>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.
> 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.<p>The "writing things down bit" is in the context of commenting. I mean, it's literally in the same paragraph.
> A lot of tech folks resist documentation because they think it provides them with job security.<p>No, we're just lazy.
Which is better than the all too common middle ground: writing something once and then not maintaining it. I've been burned many times reading some documentation and thinking I understood until I discovered the code has changed since and the documentation is now wrong.<p>I'm in favor of documentation. I write it. I get people pointing at what I've written as examples of what everybody should do. However it is a lot of work. I'm constantly looking things over to be sure it still makes sense. I often wonder if it is really worth it. I hope you follow my example and write documentation, but it better feel like a lot of work.
Occam's Razor at it's finest. I'm not trying to screw others over. I just want to not write sometimes.
It's readable, it's easy, it gets the job done.<p>I don't think that's necessarily lazy, it's just efficient
I don't agree with "readable," though. For a simple set of key-values, yes. Once you get into complicated structures, other file formats express the semantics much better.
If you have a complex configuration you are doing it wrong... Spend some time thinking about you really want and turn it into a simple key-value setup. JSON should feel like it is overpowered and bloated for your needs. (I'd still use JSON because you can find a parser and editor that can handle it, but it should feel overpowered for your needs)
> It's readable, it's easy<p>That's what I am saying about my ruby codes as well. Still my boss wanted proper commit messages
For Caddy we chose JSON because it's fairly universal, maps nearly 1:1 with Go structs (useful for initializing an extensible server), and nearly everything else compiles to JSON one way or another, so you can choose your own config format, really: <a href="https://caddyserver.com/docs/config-adapters" rel="nofollow">https://caddyserver.com/docs/config-adapters</a>
> Why do so many tools have JSON config files‽<p>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.<p>2: I suspect a lot of these tools are written in Javascript, and in Javascript JSON is very easy to work with.
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.<p><a href="https://en.wikipedia.org/wiki/Ion_(serialization_format)" rel="nofollow">https://en.wikipedia.org/wiki/Ion_(serialization_format)</a>
because JSON is in the following sense "universal":<p>every format/structure that has numbers, strings, booleans, null/none, finite lists of items, and string-indexed records of items already contains JSON<p>and that's pretty much the barebones you need for a configuration language<p>(of course you can argue about the syntax)
Lack of comments is pretty big though for a human editable <i>config</i>.
It’s just one person’s opinion, but I think two things are true enough, here…<p>1) JSON is pretty darn good for storing configuration. Everything speaks it, and a pretty printed one is very readable/tweakable in a pinch.<p>2) If you <i>insist</i> that someone <i>manually</i> edit a significant amount of it, you kinda fucked up.<p>Just my opinion, but it feels like two separate things.
You can always use JSONC or JSON5.
I just put them in as values. In a GUI I sometimes render them as a editable textarea.
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.<p><whispers>but Lua tables are even better.</whispers>
It's so simple and straightforward, and that's why Douglas Crockford claims he "discovered" it, rather than invented it.
> Why do so many tools have JSON config files‽<p>Because XML hasn't been cool for about two decades. And suggesting .ini would you laughed out of the room into retirement.
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:<p>env=staging<p>db=0.0.0.0<p>#descriptive comment<p>etc=true
TOML is a better format for configuration files IMO, if not for many reasons, primarily because TOML accepts comments.<p>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
TOML is quite ridiculous. There are always an infinity of ways one can write the same values.<p>It should really define sections as something different from dot-separated identifier groups.
Interesting. The website says that it's "validation-focused". I don't know how that plays out for TOML, but the lack of focus in json schema to define an interface in addition to validation can be very frustrating. Most of the time I would rather trade off some expressitivity in terms of validation in favor of having a defined typed interface into the validated data.
Reading and writing json is so much easier than reading or writing toml imo
I'd argue that for code, yes, JSON is vastly closer to computer structures.<p>I think this is the real <i>"why do so many tools have JSON config files":</i> 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: <i>it's mechanistic sympathy</i>.<p>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.
I find TOML is nowhere near as good as YAML. I'd even rather use jsonc.
JSON just works, everywhere, all the time. Sometimes I'll use SQLite if there is a particular need.
Because JSON is native to the lingua franca of the internet: Java-/Ecmascript.<p>It fits into the poor choices we made, <-- Parse error
Somewhat off topic, but Oracle database connection strings seem to be a form of Lisp. It makes me wonder why they would choose that.
Let me guess... if they're a form of Lisp, did someone add jndi support, then made it possible to print to the console while the string gets read and finally made it executable because who wouldn't want a LISP for-loop in an Oracle connection string? On to the next RCE...
I don't know about others, but I use JSON because it's in the standard Go library, and most of the times, I rather use something weird than add a dependency.
It would be too easy to have every option in a config file documented in comments in the default config file. Think of the poor tutorial industry. It may even make chatbots less useful.
[dead]
JSON is obviously a poor choice. It's job is to interchange data, produced and parsed by computers.<p>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.
Using an LLM to parse your application's config is a bit like using an F1 racecar to drive from your house to the bicycle in your attached garage. Getting config into the application should to be fast, light (lighter than the rest of the application), and deterministic. And if the LLM's output is easy and unambiguous to parse, it's easier to simply use that as the original config file.
Absolutely not. We do <i>not</i> want a stochastic program without any actual understanding of the schema to be interpreting config data.
> The LLM output could then be any format that's easy and unambiguous to parse.<p>Thats the problem isnt it? LLMs arent deterministic. Terrible for prod
I'm not sure why there's a problem before even trying.<p>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.<p>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.
Llms are absolutely deterministic if you want them to be.<p>Still a terrible idea for config
Don't you need the same model, on the same hardware, with the same prompt, and temperature set to 0 to make it deterministic?
[dead]