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.
Thats the problem isnt it? LLMs arent deterministic. Terrible for prod
Still a terrible idea for config
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.
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.
env=staging
db=0.0.0.0
#descriptive comment
etc=true
[section_name]
key=value
key=value
It fits into the poor choices we made, <-- Parse error
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)
1) JSON is pretty darn good for storing configuration. Everything speaks it, and a pretty printed one is very readable/tweakable in a pinch.
2) If you insist that someone manually edit a significant amount of it, you kinda fucked up.
Just my opinion, but it feels like two separate things.
<whispers>but Lua tables are even better.</whispers>
Because XML hasn't been cool for about two decades. And suggesting .ini would you laughed out of the room into retirement.
No, we're just lazy.
I don't think that's necessarily lazy, it's just efficient
That's what I am saying about my ruby codes as well. Still my boss wanted proper commit messages
Given what I know about it (single file, no auth, and such by default) I sort of understand the ”file” part I think. But not the ”config” part.
I've shipped a product that used SQLite, and we actively removed configuration from SQLite. It was a lot easier to diagnose issues when configuration was in text files, because non-programmers could kinda-sorta understand them without needing to learn how to use SQL.
Shame.
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.
brunoborges•58m ago
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
bakies•49m ago
jauntywundrkind•9m ago
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.
leni536•44m ago
Sha1rholder•34m ago
ChickeNES•28m ago