Nitpick you wonder why yaml is preferred to ini files when it is lined up to each other.
there are also some issues with keys being all string by default making some things like linting harder and allowing more less standard ways to get something done, e.g. in json true is true in init files all of true, 1, yes, y and others might be true depending on the application (but then yaml no problem is worse)
also there is no clear single standard for init files
through this is where toml comes from it took the general layout ideas behind init files but give it a strict standard and strict string vs. bool vs. float types and a bit more nesting capabilities and fixes some string distance escape issues, etc
I'm really not sure.
I mean some of the critique is very reasonable like inline tables needing to be inline but inline arrays do not.
But then they present something as INI file which most INI parser will not parse and is directly against much of their previous critique.
and why do I have the feeling that the author is constantly screaming for help internally while writing this article?
Also, YAML supports data structures that INI files don't.
I don't understand the hate that YAML gets. If you're not tasked with writing a parser, the data format just works as expected.
I fail to see what leads you to believe this is a relevant point when discussing INI files as the alternative to YAML.
INI isn't specified, thus you cannot claim that the INI format does something a certain way.
The best shot at a specified INI file format might be TOML, and even that format is subjected to the same type of criticism.
> So is JSON
Blink. I beg your pardon, JSON is strongly typed per RFC 8259 standard:
> JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays).
The type system does not align well with any other type system out there (float/int ambiguity, no timestamps, etc.) but it's still better than any coercion.
NI: Nicaragua
NL: Netherlands
NO: Norway
python: 3.2.3
numpy: 2.1
octal: 042
https://noyaml.com/ is a decent overview of exactly how shit it is.
But outside of that, using spaces for logic is extremely error prone if you go past 10-15 lines and 2-3 levels deep.
Frankly, this is a phantom benefit: the first thing people do in brackety-languages is define an indent standard. And it's not like a brackety language magically saves you from mis-nesting things if a bracket ends up misplaced.
I'm not sure this is the criticism you think it is. Wow, so you basically have to add quotes to get strings in some ambiguous situations?
Yeah sure you could probably improve YAML by getting rid of these weird pitfalls, but that is a minor improvement. The alternative isn't something like TOML, because YAML is optimized for hierarchical configuration. It's every vendor implementing a different syntax such as Hashicorp with their HCL [0].
> 2-3 levels deep.
Same to python, all non-trivial code is like 4 level+ depth, big deal!
I normally write javascript and I switch to python easily from time to time. I cannot understand people who complain about spaces.
If that site lists all the complains that nitpickers managed to put together, it sounds like YAML is virtually perfect.
Also, to underline how silly and futile these nitpicking complains are, some YAML parsers already explicitly address silly things like the Norway problem.