As a data format, yaml is extremely complicated and it has many footguns. In this post I explain some of those pitfalls by means of an example, and I suggest a few simpler and safer yaml alternatives.
A 10 minute read covering some YAML edge-cases that you should have in mind when writing complex YAML files
The problem is specifically that in’t not exactly clear what’s considered ambiguous. For instance, no is the same thing as false, but as evidenced in the linked post, in the context of country codes, it means “Norway” and it’s not obvious that it might get interpreted as a boolean value.
It’s the same thing as this famous meme about implicit type conversions in JS :
TBF (I don’t often defend JS) - one of those is just “standard floating point issues” that every developer should be aware of. Computers cannot represent an infinite array of numbers between 0 and 1.
The first four of them are “just how floats work”, yeah. Has nothing to do with JavaScript.
typeofNaN// "number"
Classic, yes, very funny. “NaN stands for ‘not a number’ but it says it’s a number”. But for real though. It’s still a variable that’s the Number type, but its contents happen to be invalid. It’s Not a (Valid) Number.
The next three are just classic floating point precision moments.
The Math.max() and Math.min() ones are interesting. Seems that under the hood, both methods implicitly have a fallback “number” that it compares to any argument list you give it that will auto-lose (or at closest, tie) with any other valid number you can possibly give it, so when you give it nothing at all, they leak out. Honestly, makes sense. Kinda ludicrous it needs to have defined behavior for a zero-argument call in the first place. But JS is one of those silly languages that lets you stuff in or omit as many arguments as you want with no consequences, function signature be damned. So as long as that paradigm exists, the zero-argument case probably ought to do something, and IMO this isn’t the worst choice.
Every other one is bog standard truthy/type coercion shitlery. A demonstration of why implicit type coercion as a language feature is stupid.
The problem is specifically that in’t not exactly clear what’s considered ambiguous. For instance,
nois the same thing asfalse, but as evidenced in the linked post, in the context of country codes, it means “Norway” and it’s not obvious that it might get interpreted as a boolean value.It’s the same thing as this famous meme about implicit type conversions in JS :
TBF (I don’t often defend JS) - one of those is just “standard floating point issues” that every developer should be aware of. Computers cannot represent an infinite array of numbers between 0 and 1.
The first four of them are “just how floats work”, yeah. Has nothing to do with JavaScript.
typeof NaN // "number"Classic, yes, very funny. “NaN stands for ‘not a number’ but it says it’s a number”. But for real though. It’s still a variable that’s the Number type, but its contents happen to be invalid. It’s Not a (Valid) Number.
The next three are just classic floating point precision moments.
The
Math.max()andMath.min()ones are interesting. Seems that under the hood, both methods implicitly have a fallback “number” that it compares to any argument list you give it that will auto-lose (or at closest, tie) with any other valid number you can possibly give it, so when you give it nothing at all, they leak out. Honestly, makes sense. Kinda ludicrous it needs to have defined behavior for a zero-argument call in the first place. But JS is one of those silly languages that lets you stuff in or omit as many arguments as you want with no consequences, function signature be damned. So as long as that paradigm exists, the zero-argument case probably ought to do something, and IMO this isn’t the worst choice.Every other one is bog standard truthy/type coercion shitlery. A demonstration of why implicit type coercion as a language feature is stupid.