because inin files have no or very limited support for nesting
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 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].
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.
This has literally never been a problem for me despite writing considerable amounts of YAML.
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 don't know if it's yaml or jinja, but variations of https://mastodon.communick.com/@raphael/111059057995356737 keeps me wishing that we dropped all these formats and just adopted some type of lisp that could be embedded in all languages.
So is JSON, and all mainstream config formats actually.
However, that stopped being a problem with JSON schema, which, despite the name, works on yaml too.
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.
I dont think expirements are a way to qualify decades of research that went before.
Second what Sun choose to implement was a smaller subset and not that close to Featherweight Java/pizza compiler. It was only generics, not first class functions at the time, nor algebraic types/pattern matching.
Awful? I think you might need to get your outrageometer checked.
I’m old enough to remember being lectured on how prude we are in the States not to have topless women in ads like the enlightened Europeans and Japanese.
I looked through the pages and saw two ads that had a woman standing with the product. Seems reasonable and unoffensive, especially for 40 years ago and compared to other industries/magazines.
It's easy to change your default shell, but if you got a shell script that explicitly specifies #!/bin/sh (and they all do) then /bin/sh will be invoked, regardless what your default shell is. So your options are to modify every script file to invoke your default shell (usually #!/usr/local/bin/sh ) or to install your default shell in /bin.