Hacker News Reader

Comment by Fischgericht | Hacker News Reader

ONE actual standard that everyone uses would be fine. For non-tree (nested) configurations, an ini file would do. It's a standard that worked well in 1990, and still does today.

For nested data, it doesn't matter to me if it's JSON, YAML, TOML or whatever. Just agree on ONE format.

TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due to "I can't stand unquoted strings". Yeah, emotional feelings about CONFIG FILE FORMATS.

And again: If your config files are so complex, how about just creating a TUI/GUI so the user can configure your program in an accessible fashion?

Anyway, yes, there is something that can be improved: Create a standard instead of adding another layer of complexity for something that should be very simple in the first place.

Yes, binary size may feel arbitrary, but it often gives a hint about the hammer's size.

View on HN

> TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due to "I can't stand unquoted strings". Yeah, emotional feelings about CONFIG FILE FORMATS.

INI is hard to parse because without quotes the parser would not know whether it’s a “True” as a string or True as Boolean value. Formal parser that can be included into a program as a library and would reliably generate internal config representation (e.g., read config file into an object in application memory that will be used to modify the behaviour) is a good thing and TOML helps with that while INI does not.

Schemas are often better than syntax typing. In other words the program decides what the type is, not the file.

If the schema allows union types, I don't want to deal with unquoted strings.

You don’t deal with syntax period. Union types are not desirable with configuration with the exception of |null perhaps, which should receive a default.

Yes, agreed. On the other hand, there are quite a few people using Javascript, a language where this distinction also isn't really done in a clean way.

If you would de-serialize an ini-file into Objects in memory you would typically have meta-data about your object (RTTI/Reflection for compiled languages, given for scripting languages).

But yes, INI isn't without flaws. Parsers typically will need to accept everything from "true", "True", True, true, 1, "1" for boolean fields.

> They deliberately (!) broke compatibility to the INI format

There is no "ini format" though? INI is a weak set of conventions that different programs parse in a completely different way, it's the opposite of standardization.

> ONE actual standard that everyone uses would be fine

Sounds like a social problem. How do you get _everyone_ to agree on anything?

It’s pretty clear that you are putting “things that I [think I] understand above things that are better. Have you ever written an ini parser? If you have, I doubt it was good, because none of them are, because ini is a flawed format.

The Python parser has worked well for decades.

No, I am a Pascal guy. Turbo Pascal had an INI parser, Delphi has one, FreePascal has one, and they all work flawlessly.

From what I see, 20+ years proven parsers are available for pretty much any language there is.

And yes, the format is a bit flawed. But it gets the job done.

Reply on news.ycombinator.com