12 ms·

The fact that YAML is so bad is why being "understandable by a human" shouldn't be the ultimate goal of any configuration language. I would gladly make concessi

by nmilo 3y ago

The fact that YAML is so bad is why being "understandable by a human" shouldn't be the ultimate goal of any configuration language. I would gladly make concessions like quoted strings or bracketed lists to avoid the hell of trying to figure out if my string/number/list actually parsed as a string/number/list.

Pxtl 3y ago
Yaml convinced me that dynamically typed config & interchange formats are a bad idea. Statically typed schema eliminate the ambiguity and so you get to have your legibility cake and eat your consistence cake too.
- kibwen 3y ago
  I used to be in favor of schemas, but my problem with them these days is that they just can't encode all the validation necessary to ensure that the config is correct. At the end of the day, the only way to check if the config is actually valid is to parse it, so I'm sympathetic to the "string them all and let the application sort them out" approach.
  - IggleSniggle 3y ago
    I'm sympathetic to that, but not to ini! INI is just standardized enough that your ini parser may or may not give you "just a string." As another poster mentioned, it may well interpret the string "NO", quotes included, as the boolean false, before passing along to the rest of the application. It's this ambiguity of type that makes INI problematic. If it simply handed along strings, without fail, and left the application to parse whether "NO" should be a country or boolean or string, that wouldn't be a problem. But inevitably, in order to DRY, somebody will make a consistent parser that is used in your application, whether that's in-house or a dependency. And at that point, it is very tempting to run everything through the parser, and the parser is going to make some unexpected decisions. So, sure, use INI. But don't really. Use a env file that is parseable as INI or as shell environment variables. As soon as you start needing anything more complex, use something where you have at least a few basic guarantees that what you're getting is at least in the general vicinity of what you want.
    - kibwen 3y ago
      Right, I'm not trying to say that INI is the solution, only that 1) TOML's anemic selection of types is probably pointless, and 2) any attempt to provide a useful selection of types would require being a Turing-complete language, which is not want I want in my config files, so you might as well just give me strings and let me parse it in the typed, Turing-complete language that I'm already using for my application logic.
  - AndyKluger 3y ago
    Absolutely agree! If you haven't checked it out, NestedText takes this approach.
    - Pxtl 3y ago
      Yes. I like the NestedText approach, but I do feel like it needs an official optional "blessed" schema description language for type validation, instead of "here's a dozen ways to do NestedText validation in python".
- hitchstory 3y ago
  thats what strictyaml does
vkazanov 3y ago
YAML is the Perl of config formats. I just don't understand how it ended up being so popular! I remember my oss editor at some being had a little problem highlighting a yaml configuration. No problem, - I thought. - how hard can that be? Well, turns out it's almost cpp level hard to properly parse the language.

by nmilo 3y ago

Pxtl 3y ago

Yaml convinced me that dynamically typed config & interchange formats are a bad idea. Statically typed schema eliminate the ambiguity and so you get to have your legibility cake and eat your consistence cake too.

kibwen 3y ago
I used to be in favor of schemas, but my problem with them these days is that they just can't encode all the validation necessary to ensure that the config is correct. At the end of the day, the only way to check if the config is actually valid is to parse it, so I'm sympathetic to the "string them all and let the application sort them out" approach.
- IggleSniggle 3y ago
  I'm sympathetic to that, but not to ini! INI is just standardized enough that your ini parser may or may not give you "just a string." As another poster mentioned, it may well interpret the string "NO", quotes included, as the boolean false, before passing along to the rest of the application. It's this ambiguity of type that makes INI problematic. If it simply handed along strings, without fail, and left the application to parse whether "NO" should be a country or boolean or string, that wouldn't be a problem. But inevitably, in order to DRY, somebody will make a consistent parser that is used in your application, whether that's in-house or a dependency. And at that point, it is very tempting to run everything through the parser, and the parser is going to make some unexpected decisions. So, sure, use INI. But don't really. Use a env file that is parseable as INI or as shell environment variables. As soon as you start needing anything more complex, use something where you have at least a few basic guarantees that what you're getting is at least in the general vicinity of what you want.
  - kibwen 3y ago
    Right, I'm not trying to say that INI is the solution, only that 1) TOML's anemic selection of types is probably pointless, and 2) any attempt to provide a useful selection of types would require being a Turing-complete language, which is not want I want in my config files, so you might as well just give me strings and let me parse it in the typed, Turing-complete language that I'm already using for my application logic.
- AndyKluger 3y ago
  Absolutely agree! If you haven't checked it out, NestedText takes this approach.
  - Pxtl 3y ago
    Yes. I like the NestedText approach, but I do feel like it needs an official optional "blessed" schema description language for type validation, instead of "here's a dozen ways to do NestedText validation in python".
hitchstory 3y ago
thats what strictyaml does

vkazanov 3y ago

YAML is the Perl of config formats. I just don't understand how it ended up being so popular! I remember my oss editor at some being had a little problem highlighting a yaml configuration. No problem, - I thought. - how hard can that be? Well, turns out it's almost cpp level hard to properly parse the language.