Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I've had a number of negative experiences with yaml, enough to put me off using it. For example the implicit parsing of 'yes' and 'no' into bools rather than strings (including the NO country code for Norway) [1], the no-quote rules allowing accidental creation of inline hashes/arrays [4], multiline string syntax so complex that it needs a helper tool [2], powerful extensions that invite your program to be exploited [3] and other obscure features (you can reference other yaml sections recursively)
It manages to be both a poor data interchange language compared to JSON, and also a bad human-friendly langage due to the above ambiguities.
Unfortunately it's still the best human-friendly configuration language in wide use, so I use [https://hitchdev.com/strictyaml/ strictyaml] instead.
[1]: https://hitchdev.com/strictyaml/why/implicit-typing-removed/
We could build such a format on top of JSON (there are probably multiple), but I again agree with Crockford that this sort of thing does not belong in JSON.
Makes for a bunch of headaches, though, for sure.
One example is a data scientist I used to work with. He was working with lots of machine learning libraries that liked to use NaN to mean "nothing to see here." A fellow developer ended up writing code that used some sort of convention to work around it, e.g. number := decimal | {"magic-uuid": "NaN"}. I can see why some people are of the opinion "this is stupid, just allow NaNs." I disagree.
[1]: https://github.com/edn-format/edn