4 ms·

This critique made me learn some new things about both formats, but I actually come out more in support of TOML because of it Each argument the author gives is

by tux3 3y ago

This critique made me learn some new things about both formats, but I actually come out more in support of TOML because of it Each argument the author gives is a strong preferrence for everything being implicit, ambiguous, free of heavy syntax like quotes for strings and brackets for arrays That would be a reasonable subjective choice, but when I see the INI exemples used to illustrate, or the slightly out there assertion that a 1 element list is a completely meaningless inhuman concept, I'm not really swayed. Sometimes it almost seems like irony. The exemples are really hard to take at face value.. If anything, this pushes me further away from that. I've done YAML. I've done languages where everything is helpfully implicitly cast, and all the "WTF talks" that result from the weird rules and edge cases. We know what it's like when DE is a string but NO is a boolean, and only some version numbers are strings while some are floats. Quoting strings is really not what costs me time and effort. It's weird edge cases and surprises that come back to bite you.

dale_glass 3y ago
I mean, it refers to Postel's law on the top. Most of it seems to follow from that. IMO that's long been proven to have been a very bad idea in retrospect. So good riddance.
- coldtea 3y ago
  >I mean, it refers to Postel's law on the top One of the crappiest ideas in CS.
  - kemotep 3y ago
    I can imagine several security issues with accepting any kind of input in your program.
    - masklinn 3y ago
      Literally every language held as a shining example of postel's law is full to the brim with security issues. The literal interpretation of Postel's Law has been considered highly detrimental for 20 years: https://datatracker.ietf.org/doc/html/rfc3117#section-4.5 https://datatracker.ietf.org/doc/html/rfc3117#section-4.5
  - sham1 3y ago
    Well it seems to work for TCP at least, which is where it comes from. Of course it's not the correct approach for everything, but calling it "one of the crappiest ideas in CS" might be a tad harsh. EDIT: Of course there are better ways to be robust than to try to just accept whatever garbage is thrown your way because "be liberal in what you accept." So for example since this is about config files, you could easily just tell the user that their stuff is wrong and tell them how to fix it.
- bunderbunder 3y ago
  I can accept Postel's Law as being a great idea for fairly low-impact things like markup languages. XHTML is a good example here: it turns out it wasn't an awesome idea, because if the author of an HTML file forgets to close a tag, I'd rather the browser make a best effort at displaying a document that might be a little janky, than show me nothing at all. But if we're talking configuration files for applications? No. Absolutely not. If I get anything even slightly off, do not under any circumstances respond by launching the application into an unpredictable state. Fail immediately and tell me why. Same principle applies for RPC messages. The reductio ad absurdum here is weak typing. If Postel's Law were actually a generally applicable law, then PHP4 would be widely considered to be the pinnacle of language design. I think most people would agree that it's closer to the nadir. But still... context matters, XHTML was a mistake. Which implies that Postel's Law is true in at least some contexts.
  - capitainenemo 3y ago
    There's still a few nice things about XHTML that I miss. It's really helpful in debugging and catching mistakes. I'll actually force it on for dev and test systems just to quickly identify errors. I've caught hundreds of issues with templates that way. Sure there are markup validators, but the always on strict was nice. And still usable with XHTML5... So long as the web page is being generated by your code, the strictness is a win I think. And you can turn off strict in browsers by serving XHTML5 as HTML5 with text/html content type. The responseXML in XHR for XHTML is really nice, and still available though mostly useless. I wish when XHTML was abandoned that a responseParsedDOM was offered to avoid some of the exploitable hacks people came up with instead. XML transforms using XSL could do some pretty nifty tricks with static docs and no other processors but your browser. So, yeah, don't feel it was wholly a mistake. Sure for random content or user generated isn't a good idea, and it'd be nice if there were clean ways to handle that (not iframes), but saying that your app shouldn't have a strict rendering is like saying JSON should be forgiving of misplaced braces... If you're feeding bad JSON to your modern JS driven app, well, that's your fault and there should be errors and it should be fixed. Similar for XHTML for your server side app IMO.
    - 3y ago
- Kinrany 3y ago
  Postel's law is for implementations of underspecified standards and for backwards compatibility, the problem is the misguided attempts to somehow use it in new standards.
MrBuddyCasino 3y ago
> Sometimes it almost seems like irony. The examples are really hard to take at face value. Agree, with a few exceptions (eg empty key names), the TOML design choice just seems less ambiguous, simpler and thus... better?
kybernetikos 3y ago
I understand your points as precisely in the opposite direction to your conclusion. According to this post, the INI approach says that the code that reads the value determines what type it should be. That approach means that you never get a problem where NO is a boolean when it should have been an enum, or a version number is a float when it should have been a string. You only get those problems when the type of a value is determined from the file without reference to the expected type, like in TOML.
- PH95VuimJjqBqy 3y ago
  and I agree with that approach personally. I don't consider YAML to be an acceptable configuration format and it kills me that the standard moved to it away from XML.
- coldtea 3y ago
  >According to this post, the INI approach says that the code that reads the value determines what type it should be. That approach means that you never get a problem where NO is a boolean when it should have been an enum, or a version number is a float when it should have been a string That's a simplistic view. In practice, there soon wont be just one piece of code reading your files, or it will be shared elsewhere, and it will all depend on implicit semantics and documentation of the assumptions (if you're lucky to have it). Hilarity, chaos, and head scratching ensues. Whereas with a format that enforces the types, every consumer with a parser for the format gets the same values (to the extended that it matters: a list doesn't suddenly become a string, but in some language it might be a vector and in another an array).
  - marcosdumay 3y ago
    Configuration files usually are only read by one piece of code. Besides, the article is correct in that the type system from TOML is completely inadequate for fully parsing the files anyway, so it will necessarily depend on implicit agreement on the semantics from every reader. IMO, configuration file formats should only ever have text as primitive type. Anything else should be defined in another layer. I completely agree with that part of the argument from the article. Then the article goes to argue that the quotes are harmful... And no, if you have a whitespace sensitive language, you need a damn good representation for strings that won't allow for ambiguity to creep in. And INI is just horrible on this.
Izkata 3y ago
> or the slightly out there assertion that a 1 element list is a completely meaningless inhuman concept Much further down in the "Immediacy" section there's a slightly better argument on that part, that a 1-element array looks like a reference to a section instead of an array.

by tux3 3y ago

dale_glass 3y ago

I mean, it refers to Postel's law on the top. Most of it seems to follow from that. IMO that's long been proven to have been a very bad idea in retrospect. So good riddance.

coldtea 3y ago
>I mean, it refers to Postel's law on the top One of the crappiest ideas in CS.
- kemotep 3y ago
  I can imagine several security issues with accepting any kind of input in your program.
  - masklinn 3y ago
    Literally every language held as a shining example of postel's law is full to the brim with security issues. The literal interpretation of Postel's Law has been considered highly detrimental for 20 years: https://datatracker.ietf.org/doc/html/rfc3117#section-4.5 https://datatracker.ietf.org/doc/html/rfc3117#section-4.5
- sham1 3y ago
  Well it seems to work for TCP at least, which is where it comes from. Of course it's not the correct approach for everything, but calling it "one of the crappiest ideas in CS" might be a tad harsh. EDIT: Of course there are better ways to be robust than to try to just accept whatever garbage is thrown your way because "be liberal in what you accept." So for example since this is about config files, you could easily just tell the user that their stuff is wrong and tell them how to fix it.
bunderbunder 3y ago
I can accept Postel's Law as being a great idea for fairly low-impact things like markup languages. XHTML is a good example here: it turns out it wasn't an awesome idea, because if the author of an HTML file forgets to close a tag, I'd rather the browser make a best effort at displaying a document that might be a little janky, than show me nothing at all. But if we're talking configuration files for applications? No. Absolutely not. If I get anything even slightly off, do not under any circumstances respond by launching the application into an unpredictable state. Fail immediately and tell me why. Same principle applies for RPC messages. The reductio ad absurdum here is weak typing. If Postel's Law were actually a generally applicable law, then PHP4 would be widely considered to be the pinnacle of language design. I think most people would agree that it's closer to the nadir. But still... context matters, XHTML was a mistake. Which implies that Postel's Law is true in at least some contexts.
- capitainenemo 3y ago
  There's still a few nice things about XHTML that I miss. It's really helpful in debugging and catching mistakes. I'll actually force it on for dev and test systems just to quickly identify errors. I've caught hundreds of issues with templates that way. Sure there are markup validators, but the always on strict was nice. And still usable with XHTML5... So long as the web page is being generated by your code, the strictness is a win I think. And you can turn off strict in browsers by serving XHTML5 as HTML5 with text/html content type. The responseXML in XHR for XHTML is really nice, and still available though mostly useless. I wish when XHTML was abandoned that a responseParsedDOM was offered to avoid some of the exploitable hacks people came up with instead. XML transforms using XSL could do some pretty nifty tricks with static docs and no other processors but your browser. So, yeah, don't feel it was wholly a mistake. Sure for random content or user generated isn't a good idea, and it'd be nice if there were clean ways to handle that (not iframes), but saying that your app shouldn't have a strict rendering is like saying JSON should be forgiving of misplaced braces... If you're feeding bad JSON to your modern JS driven app, well, that's your fault and there should be errors and it should be fixed. Similar for XHTML for your server side app IMO.
  - 3y ago
Kinrany 3y ago
Postel's law is for implementations of underspecified standards and for backwards compatibility, the problem is the misguided attempts to somehow use it in new standards.

MrBuddyCasino 3y ago

> Sometimes it almost seems like irony. The examples are really hard to take at face value. Agree, with a few exceptions (eg empty key names), the TOML design choice just seems less ambiguous, simpler and thus... better?

kybernetikos 3y ago

I understand your points as precisely in the opposite direction to your conclusion. According to this post, the INI approach says that the code that reads the value determines what type it should be. That approach means that you never get a problem where NO is a boolean when it should have been an enum, or a version number is a float when it should have been a string. You only get those problems when the type of a value is determined from the file without reference to the expected type, like in TOML.

PH95VuimJjqBqy 3y ago
and I agree with that approach personally. I don't consider YAML to be an acceptable configuration format and it kills me that the standard moved to it away from XML.
coldtea 3y ago
>According to this post, the INI approach says that the code that reads the value determines what type it should be. That approach means that you never get a problem where NO is a boolean when it should have been an enum, or a version number is a float when it should have been a string That's a simplistic view. In practice, there soon wont be just one piece of code reading your files, or it will be shared elsewhere, and it will all depend on implicit semantics and documentation of the assumptions (if you're lucky to have it). Hilarity, chaos, and head scratching ensues. Whereas with a format that enforces the types, every consumer with a parser for the format gets the same values (to the extended that it matters: a list doesn't suddenly become a string, but in some language it might be a vector and in another an array).
- marcosdumay 3y ago
  Configuration files usually are only read by one piece of code. Besides, the article is correct in that the type system from TOML is completely inadequate for fully parsing the files anyway, so it will necessarily depend on implicit agreement on the semantics from every reader. IMO, configuration file formats should only ever have text as primitive type. Anything else should be defined in another layer. I completely agree with that part of the argument from the article. Then the article goes to argue that the quotes are harmful... And no, if you have a whitespace sensitive language, you need a damn good representation for strings that won't allow for ambiguity to creep in. And INI is just horrible on this.

Izkata 3y ago

> or the slightly out there assertion that a 1 element list is a completely meaningless inhuman concept Much further down in the "Immediacy" section there's a slightly better argument on that part, that a 1-element array looks like a reference to a section instead of an array.