5 ms·

Are people not even reading about what they are using? Always read documentation or you will get burned by something completely innocuous. For example, that’s

Are people not even reading about what they are using? Always read documentation or you will get burned by something completely innocuous. For example, that’s how you get Norway missing in your config file with YAML: NI: Nicaragua NL: Netherlands NO: Norway Oops, “NO” evaluates to false like 10 other reserve words.

whatshisface 5y ago
Amazing that people use YAML if it does that.
- fennecfoxen 5y ago
  This is why I default to TOML for these sorts of lists of things.
- deleted 5y ago
  [deleted]
- viraptor 5y ago
  You just learn about the edge cases. This applies to everything. There's a number of languages where an empty list/array is truthy and a number where it's falsey. Learn the tool, do some defensive programming (always quote the strings) and you'll be fine. (This issue was recognised and since yaml 1.2 (2009) the spec says "no" is a string, packages like https://yaml.readthedocs.io/ https://yaml.readthedocs.io/ have migrated a while ago)
- Lexarius 5y ago
  That's an old YAML 1.1 behavior. It was removed in 1.2 (in 2009), though some implementations (looking at you, pyyaml) are still on 1.1.
  - account42 5y ago
    So YAML is fine with breaking compatibility in minor version bumps?
    - clcaev 5y ago
      Semver was not yet common practice when 1.2 was released.
      - account42 5y ago
        https://yaml.org/spec/1.2.0/ https://yaml.org/spec/1.2.0/ says 2009 Not breaking backwards compatibility in a minor version bump of a data format was absolutely common sense in 2009.
        clcaev 5y ago
        semver.org -- which did an amazing job popularizing this idea -- did not yet have its webpage up in July 2009 (archive.org has it in December)
  - BiteCode_dev 5y ago
    Guess what was not removed? 1 : 1,0 2: 01 3: 1.0 4: 1O 5: 0b1 6: 0x1 7: 0i1 8: hey, 8.0: oh, version: [3.1, "3.1", 3.10, "3.10"] Gives you: { "1": "1,0", "2": 1, "3": 1.0, "4": "1O", "5": 1, "6": 1, "7": "0i1", "8": "oh,", "version": [ 3.1, "3.1", 3.1, "3.10" ] } YAML turns raw literals into strings, except when the string matches a certain format. Then it may turn it into other things, like int or float, and you better know all the rules by heart and be attentive. And not introduce any typo, which of course no human ever does.
    - kangalioo 5y ago
      That's why yaml is a format for computer and json a format for humans
      - BiteCode_dev 5y ago
        And that's also why everybody use JSON to configure CI, and use YAML for REST API.
- smt88 5y ago
  In situations where I'm forced to use YAML, I just use strict JSON to avoid YAML insanity.
- 3pt14159 5y ago
  Yep. I used to love Yaml back in the day. But two things burned me. 1. Significant whitespace in a data storage file doesn't scale. Yes, eventually someone wants to dump a giant graph of data and the library breaks. 2. Intermixed context on quoteless strings. Intermixing code and data doesn't work reliably. Every where I see it tried I see it break. If you don't want quotes on your strings, then you have to put something on your keywords. A simple @no would have stopped this and other situations. As an aside, I find it stupid to have multiple names for true, false, and null.
peanutz454 5y ago
> Read documentation What is this strange concept you bring up? Googling saved me an entire day of reading dry documents. I may not know how the code works, but I go around telling everyone how easy coding is because of copy+paste.
- TameAntelope 5y ago
  I'd expect my IDE to highlight keywords!
edgyquant 5y ago
I always read documentation. I just have to run into issues because I haven’t read it before I do. I imagine most engineers are like this as we tend to prefer learning by doing
thrwn_frthr_awy 5y ago
Did you read the entire YAML spec before using it (https://yaml.org/spec/1.2-old/spec.html_ https://yaml.org/spec/1.2-old/spec.html_? And all other specs? And docs for all your dependencies? What about docs for system services on all your servers? Software/specs/formats have edge-cases. Theses exists usually because of a tradeoff in usability. That's why there is YAML, JSON, TOML, etc. Choose the one that best fits your use-case and the strictness you need.
- PragmaticPulp 5y ago
  > Did you read the entire YAML spec before using it (https://yaml.org/spec/1.2-old/spec.html_ https://yaml.org/spec/1.2-old/spec.html_? This feels like an attempt at victim blaming. If you have to read an entire spec from top to bottom to avoid a pitfall in a relatively common operation, maybe something is wrong. FWIW, I couldn't even find the relevant section in that spec from a quick glance. I probably would have to read a significant portion of that spec just to figure out where it went wrong.
  - thrwn_frthr_awy 5y ago
    > This feels like an attempt at victim blaming I don't think I understand what this means in context of my comment. Are you referring to the parent of my comment? Someone wrote an article about an interesting thing they discovered about a well-known spec and OP's response is "Are people not even reading about what they are using?" Did the author of the article do something wrong?
    - yjftsjthsd-h 5y ago
      No, it's to your comment. One obvious reading of "did you read every relevant spec completely" is that if you didn't read every relevant spec 100% cover to cover then it's your fault that your software had a problem with that spec, and a reasonable person could view that as infeasible (those things get really long). Hence, it's easy to see your comment as victim blaming. (I'm not saying that I do or don't agree with that view, just trying to make sure everyone understands each other.)
clcaev 5y ago
This was a hugely bad idea; it was addressed years ago in 1.2 ... but so many 1.1 implementations
chakkepolja 5y ago
maybe lame question but doesn't syntax highlighting make NO different color because it's a reserved word? If config file is autogenerated then it's a different matter.
CipherThrowaway 5y ago
Reading often doesn't save you from gotchas. Usually it just makes you think "oh, right! I remember this bullshit from the spec" after you've been stung.
milliams 5y ago
YAML's parsing of `no` as `False` has not been part of the spec for 13 years now. It was changed in YAML 1.2 in 2009 to only be `true` and `false` (with variations in case allowed I think).

whatshisface 5y ago

Amazing that people use YAML if it does that.

fennecfoxen 5y ago
This is why I default to TOML for these sorts of lists of things.
deleted 5y ago
[deleted]
viraptor 5y ago
You just learn about the edge cases. This applies to everything. There's a number of languages where an empty list/array is truthy and a number where it's falsey. Learn the tool, do some defensive programming (always quote the strings) and you'll be fine. (This issue was recognised and since yaml 1.2 (2009) the spec says "no" is a string, packages like https://yaml.readthedocs.io/ https://yaml.readthedocs.io/ have migrated a while ago)
Lexarius 5y ago
That's an old YAML 1.1 behavior. It was removed in 1.2 (in 2009), though some implementations (looking at you, pyyaml) are still on 1.1.
- account42 5y ago
  So YAML is fine with breaking compatibility in minor version bumps?
  - clcaev 5y ago
    Semver was not yet common practice when 1.2 was released.
    - account42 5y ago
      https://yaml.org/spec/1.2.0/ https://yaml.org/spec/1.2.0/ says 2009 Not breaking backwards compatibility in a minor version bump of a data format was absolutely common sense in 2009.
      - clcaev 5y ago
        semver.org -- which did an amazing job popularizing this idea -- did not yet have its webpage up in July 2009 (archive.org has it in December)
- BiteCode_dev 5y ago
  Guess what was not removed? 1 : 1,0 2: 01 3: 1.0 4: 1O 5: 0b1 6: 0x1 7: 0i1 8: hey, 8.0: oh, version: [3.1, "3.1", 3.10, "3.10"] Gives you: { "1": "1,0", "2": 1, "3": 1.0, "4": "1O", "5": 1, "6": 1, "7": "0i1", "8": "oh,", "version": [ 3.1, "3.1", 3.1, "3.10" ] } YAML turns raw literals into strings, except when the string matches a certain format. Then it may turn it into other things, like int or float, and you better know all the rules by heart and be attentive. And not introduce any typo, which of course no human ever does.
  - kangalioo 5y ago
    That's why yaml is a format for computer and json a format for humans
    - BiteCode_dev 5y ago
      And that's also why everybody use JSON to configure CI, and use YAML for REST API.
smt88 5y ago
In situations where I'm forced to use YAML, I just use strict JSON to avoid YAML insanity.
3pt14159 5y ago
Yep. I used to love Yaml back in the day. But two things burned me. 1. Significant whitespace in a data storage file doesn't scale. Yes, eventually someone wants to dump a giant graph of data and the library breaks. 2. Intermixed context on quoteless strings. Intermixing code and data doesn't work reliably. Every where I see it tried I see it break. If you don't want quotes on your strings, then you have to put something on your keywords. A simple @no would have stopped this and other situations. As an aside, I find it stupid to have multiple names for true, false, and null.

peanutz454 5y ago

> Read documentation What is this strange concept you bring up? Googling saved me an entire day of reading dry documents. I may not know how the code works, but I go around telling everyone how easy coding is because of copy+paste.

TameAntelope 5y ago
I'd expect my IDE to highlight keywords!

edgyquant 5y ago

I always read documentation. I just have to run into issues because I haven’t read it before I do. I imagine most engineers are like this as we tend to prefer learning by doing

thrwn_frthr_awy 5y ago

Did you read the entire YAML spec before using it (https://yaml.org/spec/1.2-old/spec.html_ https://yaml.org/spec/1.2-old/spec.html_? And all other specs? And docs for all your dependencies? What about docs for system services on all your servers? Software/specs/formats have edge-cases. Theses exists usually because of a tradeoff in usability. That's why there is YAML, JSON, TOML, etc. Choose the one that best fits your use-case and the strictness you need.

PragmaticPulp 5y ago
> Did you read the entire YAML spec before using it (https://yaml.org/spec/1.2-old/spec.html_ https://yaml.org/spec/1.2-old/spec.html_? This feels like an attempt at victim blaming. If you have to read an entire spec from top to bottom to avoid a pitfall in a relatively common operation, maybe something is wrong. FWIW, I couldn't even find the relevant section in that spec from a quick glance. I probably would have to read a significant portion of that spec just to figure out where it went wrong.
- thrwn_frthr_awy 5y ago
  > This feels like an attempt at victim blaming I don't think I understand what this means in context of my comment. Are you referring to the parent of my comment? Someone wrote an article about an interesting thing they discovered about a well-known spec and OP's response is "Are people not even reading about what they are using?" Did the author of the article do something wrong?
  - yjftsjthsd-h 5y ago
    No, it's to your comment. One obvious reading of "did you read every relevant spec completely" is that if you didn't read every relevant spec 100% cover to cover then it's your fault that your software had a problem with that spec, and a reasonable person could view that as infeasible (those things get really long). Hence, it's easy to see your comment as victim blaming. (I'm not saying that I do or don't agree with that view, just trying to make sure everyone understands each other.)

clcaev 5y ago

This was a hugely bad idea; it was addressed years ago in 1.2 ... but so many 1.1 implementations

chakkepolja 5y ago

maybe lame question but doesn't syntax highlighting make NO different color because it's a reserved word? If config file is autogenerated then it's a different matter.

CipherThrowaway 5y ago

Reading often doesn't save you from gotchas. Usually it just makes you think "oh, right! I remember this bullshit from the spec" after you've been stung.

milliams 5y ago

YAML's parsing of `no` as `False` has not been part of the spec for 13 years now. It was changed in YAML 1.2 in 2009 to only be `true` and `false` (with variations in case allowed I think).