4 ms·

YAML is a bit bonkers in that it's a superset of JSON (all valid JSON is valid YAML), so if you don't like the whitespace sensitivity, you can write your YAML l

YAML is a bit bonkers in that it's a superset of JSON (all valid JSON is valid YAML), so if you don't like the whitespace sensitivity, you can write your YAML like this: { a: 42, # But you can have comments! b: "hello world", c: "and multi-line strings!", # and trailing commas! }

tomrod 8y ago
Oh hey, a Python dictionary that throws an error. Just kidding -- faced a JSON parsing issue today and this made me smile. It's a step up from XML though.
- pjmlp 8y ago
  For me lack of validation and comments are many steps down, not up.
  - zamadatix 8y ago
    Lack of validation?
    - pjmlp 8y ago
      JSON files don't have validation support like XML schema does.
      - mdaniel 8y ago
        Maybe not built in like DTD, closer to XML Schema in its laid-on-top manner, but I would argue that JSON Schema is fairly good, and on its way to becoming an IETF standard: http://json-schema.org/ http://json-schema.org/ and https://tools.ietf.org/html/draft-handrews-json-schema-01 https://tools.ietf.org/html/draft-handrews-json-schema-01 (et al) The lack of obvious namespace management is suboptimal, but so far I thankfully haven't encountered a situation where it was a show-stopper. IntelliJ and related tools also allow associating a json schema with a YAML file, which I have found infinitely handy
      - atombender 8y ago
        JSON Schema is actually pretty great.
crdoconnor 8y ago
I wrote a pared down version of YAML because while I like the basic structure I hated the complicated bullshit like the "we also parse JSON" layered on top: https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml Worse than JSON though, is the Norway problem. If you remove this stuff and start validating it properly it becomes much easier to maintain.
- brownbat 8y ago
  > the Norway problem Huh: https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/ I've always liked YAML, it's always seemed pretty intuitive to me coming from Python, and I like human-readable resource files, but those are some pretty damning counterexamples.
  - int_19h 8y ago
    JSON.NET has an insane default "smart deserialization" mode which checks if string values are valid ISO dates, and if so, deserializes them to DateTime. The result is that your typical unsuspecting app works fine for a long time, until the user just happens to throw data at it that has a date-like string in it somewhere - and so the app code gets a DateTime instance where it expected a string. And depending on how exactly it was accessed, this can go two ways. The best case is that the app just gets the value via the untyped API, casts it to string, and blows up with an invalid cast - best because you actually know what went wrong. The worst case is when the app specifically tells JSON.NET that it wants a string value (via generic type parameters), at which point it will helpfully implicitly convert the actual date value back to a string... except it can reformat it, and even helpfully adjust it from one timezone to another. Semantically it's the same date, of course, but it's not at all the same string, and sometimes that matters a lot. So this is the worst case because it's just silent data corruption. For some mysterious reason, the author believes that this is acceptable default behavior - i.e. "it's a feature, not a bug". It's especially ironic to look at all the mentions in GitHub ticket, as various projects that rely on the library run into this issue (one of them is mine): https://github.com/JamesNK/Newtonsoft.Json/issues/862 https://github.com/JamesNK/Newtonsoft.Json/issues/862
laumars 8y ago
I'll be honest, I didn't believe you at first so I went and tested some JSON against a few YAML parsers and it's completely true. This is insane. I already knew writing a YAML unmashaller was a needlessly complicated affair - and that was before I realised this could happen.

tomrod 8y ago

Oh hey, a Python dictionary that throws an error. Just kidding -- faced a JSON parsing issue today and this made me smile. It's a step up from XML though.

pjmlp 8y ago
For me lack of validation and comments are many steps down, not up.
- zamadatix 8y ago
  Lack of validation?
  - pjmlp 8y ago
    JSON files don't have validation support like XML schema does.
    - mdaniel 8y ago
      Maybe not built in like DTD, closer to XML Schema in its laid-on-top manner, but I would argue that JSON Schema is fairly good, and on its way to becoming an IETF standard: http://json-schema.org/ http://json-schema.org/ and https://tools.ietf.org/html/draft-handrews-json-schema-01 https://tools.ietf.org/html/draft-handrews-json-schema-01 (et al) The lack of obvious namespace management is suboptimal, but so far I thankfully haven't encountered a situation where it was a show-stopper. IntelliJ and related tools also allow associating a json schema with a YAML file, which I have found infinitely handy
    - atombender 8y ago
      JSON Schema is actually pretty great.

crdoconnor 8y ago

I wrote a pared down version of YAML because while I like the basic structure I hated the complicated bullshit like the "we also parse JSON" layered on top: https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml Worse than JSON though, is the Norway problem. If you remove this stuff and start validating it properly it becomes much easier to maintain.

brownbat 8y ago
> the Norway problem Huh: https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/ I've always liked YAML, it's always seemed pretty intuitive to me coming from Python, and I like human-readable resource files, but those are some pretty damning counterexamples.
- int_19h 8y ago
  JSON.NET has an insane default "smart deserialization" mode which checks if string values are valid ISO dates, and if so, deserializes them to DateTime. The result is that your typical unsuspecting app works fine for a long time, until the user just happens to throw data at it that has a date-like string in it somewhere - and so the app code gets a DateTime instance where it expected a string. And depending on how exactly it was accessed, this can go two ways. The best case is that the app just gets the value via the untyped API, casts it to string, and blows up with an invalid cast - best because you actually know what went wrong. The worst case is when the app specifically tells JSON.NET that it wants a string value (via generic type parameters), at which point it will helpfully implicitly convert the actual date value back to a string... except it can reformat it, and even helpfully adjust it from one timezone to another. Semantically it's the same date, of course, but it's not at all the same string, and sometimes that matters a lot. So this is the worst case because it's just silent data corruption. For some mysterious reason, the author believes that this is acceptable default behavior - i.e. "it's a feature, not a bug". It's especially ironic to look at all the mentions in GitHub ticket, as various projects that rely on the library run into this issue (one of them is mine): https://github.com/JamesNK/Newtonsoft.Json/issues/862 https://github.com/JamesNK/Newtonsoft.Json/issues/862

laumars 8y ago

I'll be honest, I didn't believe you at first so I went and tested some JSON against a few YAML parsers and it's completely true. This is insane. I already knew writing a YAML unmashaller was a needlessly complicated affair - and that was before I realised this could happen.