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.
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.
I totally get that. The application shouldn't use an LLM to parse the config file, but it would be useful to write one. An LLM could supply a diff to make the changes you want without learning the config-language-du-jour.
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.
Same model. Same hardware... Depends. If you sacrifice speed then no. Ieee754 is pretty specifically specified, the issue is that it's not associative. If you get the associativity correct, then there's no issue. Associativity usually dies due to scheduling
Comments
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.
Absolutely not. We do not want a stochastic program without any actual understanding of the schema to be interpreting config data.
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.
I totally get that. The application shouldn't use an LLM to parse the config file, but it would be useful to write one. An LLM could supply a diff to make the changes you want without learning the config-language-du-jour.
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.
Llms are absolutely deterministic if you want them to be.
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?
Same model. Same hardware... Depends. If you sacrifice speed then no. Ieee754 is pretty specifically specified, the issue is that it's not associative. If you get the associativity correct, then there's no issue. Associativity usually dies due to scheduling