4 ms·

I kinda get where the author is coming from. Everyone is rushing over themselves to try and "fix" configuration file formats by adding more and more complexity

I kinda get where the author is coming from. Everyone is rushing over themselves to try and "fix" configuration file formats by adding more and more complexity so we humans can express more complex data types into configuration files. Nowadays TOML is the new hotness, 6 years ago it was YML, 9 years ago it was JSON and before that XML was our alledged savior. Ultimately there's no one perfect solution, but INI does have one thing going for it: it is dead simple. It has no type system and it leaves it up to the application to convert a set of key/value string pairs (grouped by a header) into something meaningful rather than attempting to guess and spitting out unexpected surprises. Contrast to XML which has 50 ways to say the same thing depending on what tickles your fancy, YML which is probably the configuration language with the fastest footguns in the West or TOML which attempts to express fairly complicated data types into a configuration file without questioning if that's even useful for 99% of the configuration files. The only one that is close to equal in simplicity is JSON, which only allows booleans, numbers, strings and arrays/dictionaries. Really I think the only reason why JSON failed the "human-written configuration file" contest is because spec-compliant implementations forbid comments. This being mostly because the author of the spec wanted to avoid JSON (de)serializers from putting custom logic in them. (Although I'll note that JSON specifically tends to have the most non-spec-compliant libraries that have a looser stance on it and allow in-line comments using javascripts rules, at least in my experience and even has a bunch of dedicated offshoot specs that are basically "JSON but with comments".)

marcosdumay 3y ago
> Nowadays TOML is the new hotness, 6 years ago it was YML, 9 years ago it was JSON and before that XML was our alledged savior. Hum... Didn't you notice that complexity is not steadily increasing on that progression you pointed out? Anyway, INI is so simple that it doesn't even have an specification. So, I'd recommend people to avoid it.
- noirscape 3y ago
  Yeah, I noticed - that's mostly just because of the general flow of trends. XML was a hard swing in terms of complexity - it allowed you express everything, but did it in such a way that very few people would actually enjoy writing it. So it fell out of favor and folks moved to JSON for its simplicity. Then JSON proved to be somewhat too onerous because of several tiny annoyances (lack of comments, but also things like not allowing trailing commas in lists/dictionaries), so devs started trying out YML. YML quickly proved to have too many footguns because of the way its parser behaves, so it is now being abandoned in favor of TOML. Trends are a pendulum. They go back and forth, slightly changing each time they do. Complexity falls out of favor so we move to simplicity. Simplicity proves too simple so we go back to complexity, but slightly different than the old one. That too will fall out of favor and we go back to a slightly different kind of simplicity. Just how it goes. As for TOML - it's fine, I'd probably use it for a new project, but it's also undeniable that TOML in general feels a lot like supercharged INI. And that should in turn ask the question: why do we need that supercharged INI. Why should a config parser decide what primitives to return/what objects to construct them to? We can bolt schemas and other stuff on top of config parsers all we want, but why should that be the task of the parser? INI only deals in strings. In many ways, that make things a lot easier. Most static typed languages I've worked with tend to bolt getPrimitive() functions onto their config parsers for every type that throw an exception if it can't understand the type (which also makes the API extremely messy to read). Meanwhile most soft/duck-typed languages just throw you in the depths of it and give you whatever the fuck they parsed out of it. Usually you just end up manually type checking the data after. With INI, all you have is strings. It's simple, it's clean and it doesn't need to infer anything else (which also fits nicely with paradigms like "do one thing, and do it well").
AndyKluger 3y ago
> The only one that is close to equal in simplicity is JSON, which only allows booleans, numbers, strings and arrays/dictionaries. NestedText only allows strings, arrays, and dictionaries, has a proper specification, and you never need to escape anything.

marcosdumay 3y ago

> Nowadays TOML is the new hotness, 6 years ago it was YML, 9 years ago it was JSON and before that XML was our alledged savior. Hum... Didn't you notice that complexity is not steadily increasing on that progression you pointed out? Anyway, INI is so simple that it doesn't even have an specification. So, I'd recommend people to avoid it.

noirscape 3y ago
Yeah, I noticed - that's mostly just because of the general flow of trends. XML was a hard swing in terms of complexity - it allowed you express everything, but did it in such a way that very few people would actually enjoy writing it. So it fell out of favor and folks moved to JSON for its simplicity. Then JSON proved to be somewhat too onerous because of several tiny annoyances (lack of comments, but also things like not allowing trailing commas in lists/dictionaries), so devs started trying out YML. YML quickly proved to have too many footguns because of the way its parser behaves, so it is now being abandoned in favor of TOML. Trends are a pendulum. They go back and forth, slightly changing each time they do. Complexity falls out of favor so we move to simplicity. Simplicity proves too simple so we go back to complexity, but slightly different than the old one. That too will fall out of favor and we go back to a slightly different kind of simplicity. Just how it goes. As for TOML - it's fine, I'd probably use it for a new project, but it's also undeniable that TOML in general feels a lot like supercharged INI. And that should in turn ask the question: why do we need that supercharged INI. Why should a config parser decide what primitives to return/what objects to construct them to? We can bolt schemas and other stuff on top of config parsers all we want, but why should that be the task of the parser? INI only deals in strings. In many ways, that make things a lot easier. Most static typed languages I've worked with tend to bolt getPrimitive() functions onto their config parsers for every type that throw an exception if it can't understand the type (which also makes the API extremely messy to read). Meanwhile most soft/duck-typed languages just throw you in the depths of it and give you whatever the fuck they parsed out of it. Usually you just end up manually type checking the data after. With INI, all you have is strings. It's simple, it's clean and it doesn't need to infer anything else (which also fits nicely with paradigms like "do one thing, and do it well").

AndyKluger 3y ago

> The only one that is close to equal in simplicity is JSON, which only allows booleans, numbers, strings and arrays/dictionaries. NestedText only allows strings, arrays, and dictionaries, has a proper specification, and you never need to escape anything.