6 ms·

I way prefer XML over something like YAML. I can't believe people criticize XML for being too complex and then rave about YAML. YAML is a monstrosity, the spec

by ajnin 5y ago

I way prefer XML over something like YAML. I can't believe people criticize XML for being too complex and then rave about YAML. YAML is a monstrosity, the spec is something like 700 pages, and is a frequent source of bugs. To me at least indentation-based hierarchy is also hard to read, XML is verbose but at least you know where you are. JSON would be fine, but some values are not representable, and as the article says, you can't embed any comments, and also the order of input is not preserved. I don't think that is really appropriate for manually-edited files. The quest for the perfect data and configuration language is still on.

tored 5y ago
YAML is not only hard to read it also hard to properly parse and generate. I once tried to read the parser code for the Symfony YAML library, horrible, and that is not a critique against the developers of that library, the format is just too complex.
- whoisthemachine 5y ago
  Also hard to edit. Why do we use YAML again?
  - curtis3389 5y ago
    Because noone wants to dump a ton of work into a JSON parser they can't say is standards-compliant because it also supports C-style comments?
    - whoisthemachine 5y ago
      Hm it is interesting that your hypothesis is solely the exclusion of comments from JSON. I can understand the constraint when you consider JSON as a data transmission spec rather than a configuration spec. I also find TOML to be much a cleaner syntax than either of the two, but maybe we should just give up and make a JSON-C (for Configuration, I just made this) which supports comments.
      - hathawsh 5y ago
        FWIW, JSON5 and Hjson share those goals. https://json5.org/ https://json5.org/ https://hjson.github.io/ https://hjson.github.io/
      - samatman 5y ago
        Or just use TOML when it's appropriate; that's what I do, and I haven't had cause to regret it. One can usually answer the question "am I going to frequently have deeply-nested tables and/or long strings for keys" in advance, and if the answer is no then TOML is practically ideal. If it proves to be wrong occasionally than JSON is a reasonable fallback, as is just coping with the verbosity of TOML.
      - nigeltao 5y ago
        See JWCC (JSON With Commas and Comments) https://nigeltao.github.io/blog/2021/json-with-commas-comments.html https://nigeltao.github.io/blog/2021/json-with-commas-commen...
      - chris37879 5y ago
        I'm not sure if it comes from a plugin or not, but that's one of the options I have in VSCodes language dropdown, JSON with comments, and it's exactly what the name says, it's json, but it doesn't die on // style comments. It also kicks in if I name the file with .jsonc as the extension.
  - jerf 5y ago
    Because people confuse goals with results. Someone comes along claiming "I've got an easy-to-edit format!", or even better, "I've got an easier-to-edit format than that horrible thing X you all hate!", and there's a whole whackload of people who will accept that statement as essentially proof without looking to see if the goals have actually manifested as a result in the real world. This isn't a snipe at YAML specifically. It's a repeated pattern I've seen with many technologies. There's a certain mode of advocacy you can use to invoke this on a certain set of the programmer population, and it works reasonably often. (The "better than the X you all hate!" part may be obligatory; I haven't studied this in a careful academic sense, I've just observed this pattern a few times. Leveraging an emotional reaction against some tech and using it to suppress a rational examination of the proposed replacement on its own terms may be the mechanism of how this is done.)
    - whoisthemachine 5y ago
      I think this is definitely part of it - it's an instinct I fight myself to just accept a headline that says "X will be Bad!" or "Y is Better Than Z!". Human nature is a tricky beast :)
  - HotHotLava 5y ago
    Since someone linked both standards elsewhere in the thread, this is the first valid, self-contained example XML document appearing in the XML spec: <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE greeting [ <!ELEMENT greeting (#PCDATA)> ]> <greeting>Hello, world!</greeting> The first example of a complete, self-contained yaml document in the yaml spec looks like this: # Ranking of 1998 home runs --- - Mark McGwire - Sammy Sosa - Ken Griffey # Team ranking --- - Chicago Cubs - St Louis Cardinals I think that is quite representative of the user experience as a whole: Yes, there are a ton of dark corners in Yaml that only a tiny fraction of people truly understand, but the default user experience feels just like writing a slightly more convenient JSON, whereas XML by default is a garbled mess.
    - kaba0 5y ago
      It’s easy to specialize to a tiny tiny subset of all the problems XML can solve by.. not solving those at all
  - thiht 5y ago
    Because not everyone agrees on that. I find YAML to be both extremely easy to read and write. Yes, YAML has some stupid features. Just don’t use them? It’s clearly not perfect but IMO it’s the best right now.
  - paulddraper 5y ago
    > Why do we use YAML again? Because we want a low-noise human configuration language. XML and JSON certainly aren't it. TOML and HOCON are low-noise, but share many of YAML's drawbacks.
CodesInChaos 5y ago
I'd go with TOML for simple configurations. It has its flaws (numbers are doubles and multi-line strings are plantform dependent), but editing by hand is reasonable and it's not as complex as YAML.
- tored 5y ago
  Haven't used TOML but it looks nice, having something that is similar to INI is good idea.
- xrstf 5y ago
  I find it incredibly hard to understand anything in TOML that is more than simple, unnested key-value pairs. If you get into arrays, maps etc. then TOML is a nightmare to read. The "O" in TOML is not deserved in my opinion.
- speed_spread 5y ago
  I find TOML even worse. While it dodges some of YAML's issues, it can't decide if it's a super-INI file or another super-JSON. Also there is no way to format it to hint the human reader about the tree structure, making it un-navigatable.
fouc 5y ago
You seem to be off by a factor of 10. YAML spec pdf is only 80 pages. https://yaml.org/spec/1.2/spec.pdf https://yaml.org/spec/1.2/spec.pdf
- Mikhail_Edoshin 5y ago
  When I print preview XML 1.0 [1], it says '41 pages', so it's about half of YAML. (And this includes DTD.) [1] https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/
  - fanf2 5y ago
    but it doesn't include namespaces
    - Mikhail_Edoshin 5y ago
      Namespaces [1] will add 13 more pages. It's a tiny extension. [1] https://www.w3.org/TR/REC-xml-names/ https://www.w3.org/TR/REC-xml-names/
- ajnin 5y ago
  OK I was way off, the sheer complexity definitely feels like 700 pages though ;)
marcosdumay 5y ago
XML is way more complex than YAML. XML has not only all the indirection troubles of YAML, but even freer indirection (you can point to the web!), partial data, substandards, foreign includes, and a lot of extra things. Just like YAML, there exist a sound subset of XML that is quite usable. Just like YAML, XML is hard to write correctly, but I would say the XML errors are much easier to spot. Both JSON and YAML have the problem of lacking tagged unions. Also, the XML data definition can be either extra complexity or a great tool depending on your usage. (But DTDs use an atrocious language either way.) None of those 3 standards have a really universal type representation, and while there are substandards for XML that extend the types, I've never seen anything that could encode even the C type system.
- GoblinSlayer 5y ago
  Yep, anything is hard to write. What's more important, YAML is hard to read, and it's by design as its markup was intended to be as invisible as possible.
  - marcosdumay 5y ago
    Hum... JSON is quite easy to write. Too bad the lack of comments makes it unmaintainable. As the OP said, the quest for the perfect data language is still on.
    - GoblinSlayer 5y ago
      Hard to write as in you can botch it up. With JSON you need to be careful to close all the tiny braces, sometimes far apart.
  - rishav_sharan 5y ago
    First time I have heard that YAML is harder to read compared to XML. XML might have many upsides over YAML, but readability isn't one of them
    - GoblinSlayer 5y ago
dehrmann 5y ago
> and is a frequent source of bugs Poor Norway. https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/
sinyug 5y ago
> I way prefer XML over something like YAML. So do I. XML is sane and has a lot of tooling readily available. YAML, with its significant white space, is one of the shittiest formats that I have ever encountered.
jdhawk 5y ago
https://json5.org/ https://json5.org/ comments. trailing commas
- nigeltao 5y ago
  JWCC (JSON With Commas and Comments) gives you exactly that, without other things that are arguably a mistake. https://nigeltao.github.io/blog/2021/json-with-commas-comments.html#why-not-json5-jsonc-1-hjson-or-hocon-instead https://nigeltao.github.io/blog/2021/json-with-commas-commen...
  - fomine3 5y ago
    What VSCode use is JSONC, only allow comments https://github.com/microsoft/vscode/issues/100688 https://github.com/microsoft/vscode/issues/100688
paulddraper 5y ago
YAML is absolutely horrendous. What are the types in the following YAML document? a: true b: on c: yes d: TrUE e: aye It's as if the designers craved inconsistency.

by ajnin 5y ago

tored 5y ago

YAML is not only hard to read it also hard to properly parse and generate. I once tried to read the parser code for the Symfony YAML library, horrible, and that is not a critique against the developers of that library, the format is just too complex.

whoisthemachine 5y ago
Also hard to edit. Why do we use YAML again?
- curtis3389 5y ago
  Because noone wants to dump a ton of work into a JSON parser they can't say is standards-compliant because it also supports C-style comments?
  - whoisthemachine 5y ago
    Hm it is interesting that your hypothesis is solely the exclusion of comments from JSON. I can understand the constraint when you consider JSON as a data transmission spec rather than a configuration spec. I also find TOML to be much a cleaner syntax than either of the two, but maybe we should just give up and make a JSON-C (for Configuration, I just made this) which supports comments.
    - hathawsh 5y ago
      FWIW, JSON5 and Hjson share those goals. https://json5.org/ https://json5.org/ https://hjson.github.io/ https://hjson.github.io/
    - samatman 5y ago
      Or just use TOML when it's appropriate; that's what I do, and I haven't had cause to regret it. One can usually answer the question "am I going to frequently have deeply-nested tables and/or long strings for keys" in advance, and if the answer is no then TOML is practically ideal. If it proves to be wrong occasionally than JSON is a reasonable fallback, as is just coping with the verbosity of TOML.
    - nigeltao 5y ago
      See JWCC (JSON With Commas and Comments) https://nigeltao.github.io/blog/2021/json-with-commas-comments.html https://nigeltao.github.io/blog/2021/json-with-commas-commen...
    - chris37879 5y ago
      I'm not sure if it comes from a plugin or not, but that's one of the options I have in VSCodes language dropdown, JSON with comments, and it's exactly what the name says, it's json, but it doesn't die on // style comments. It also kicks in if I name the file with .jsonc as the extension.
- jerf 5y ago
  Because people confuse goals with results. Someone comes along claiming "I've got an easy-to-edit format!", or even better, "I've got an easier-to-edit format than that horrible thing X you all hate!", and there's a whole whackload of people who will accept that statement as essentially proof without looking to see if the goals have actually manifested as a result in the real world. This isn't a snipe at YAML specifically. It's a repeated pattern I've seen with many technologies. There's a certain mode of advocacy you can use to invoke this on a certain set of the programmer population, and it works reasonably often. (The "better than the X you all hate!" part may be obligatory; I haven't studied this in a careful academic sense, I've just observed this pattern a few times. Leveraging an emotional reaction against some tech and using it to suppress a rational examination of the proposed replacement on its own terms may be the mechanism of how this is done.)
  - whoisthemachine 5y ago
    I think this is definitely part of it - it's an instinct I fight myself to just accept a headline that says "X will be Bad!" or "Y is Better Than Z!". Human nature is a tricky beast :)
- HotHotLava 5y ago
  Since someone linked both standards elsewhere in the thread, this is the first valid, self-contained example XML document appearing in the XML spec: <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE greeting [ <!ELEMENT greeting (#PCDATA)> ]> <greeting>Hello, world!</greeting> The first example of a complete, self-contained yaml document in the yaml spec looks like this: # Ranking of 1998 home runs --- - Mark McGwire - Sammy Sosa - Ken Griffey # Team ranking --- - Chicago Cubs - St Louis Cardinals I think that is quite representative of the user experience as a whole: Yes, there are a ton of dark corners in Yaml that only a tiny fraction of people truly understand, but the default user experience feels just like writing a slightly more convenient JSON, whereas XML by default is a garbled mess.
  - kaba0 5y ago
    It’s easy to specialize to a tiny tiny subset of all the problems XML can solve by.. not solving those at all
- thiht 5y ago
  Because not everyone agrees on that. I find YAML to be both extremely easy to read and write. Yes, YAML has some stupid features. Just don’t use them? It’s clearly not perfect but IMO it’s the best right now.
- paulddraper 5y ago
  > Why do we use YAML again? Because we want a low-noise human configuration language. XML and JSON certainly aren't it. TOML and HOCON are low-noise, but share many of YAML's drawbacks.

CodesInChaos 5y ago

I'd go with TOML for simple configurations. It has its flaws (numbers are doubles and multi-line strings are plantform dependent), but editing by hand is reasonable and it's not as complex as YAML.

tored 5y ago
Haven't used TOML but it looks nice, having something that is similar to INI is good idea.
xrstf 5y ago
I find it incredibly hard to understand anything in TOML that is more than simple, unnested key-value pairs. If you get into arrays, maps etc. then TOML is a nightmare to read. The "O" in TOML is not deserved in my opinion.
speed_spread 5y ago
I find TOML even worse. While it dodges some of YAML's issues, it can't decide if it's a super-INI file or another super-JSON. Also there is no way to format it to hint the human reader about the tree structure, making it un-navigatable.

fouc 5y ago

You seem to be off by a factor of 10. YAML spec pdf is only 80 pages. https://yaml.org/spec/1.2/spec.pdf https://yaml.org/spec/1.2/spec.pdf

Mikhail_Edoshin 5y ago
When I print preview XML 1.0 [1], it says '41 pages', so it's about half of YAML. (And this includes DTD.) [1] https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/
- fanf2 5y ago
  but it doesn't include namespaces
  - Mikhail_Edoshin 5y ago
    Namespaces [1] will add 13 more pages. It's a tiny extension. [1] https://www.w3.org/TR/REC-xml-names/ https://www.w3.org/TR/REC-xml-names/
ajnin 5y ago
OK I was way off, the sheer complexity definitely feels like 700 pages though ;)

marcosdumay 5y ago

XML is way more complex than YAML. XML has not only all the indirection troubles of YAML, but even freer indirection (you can point to the web!), partial data, substandards, foreign includes, and a lot of extra things. Just like YAML, there exist a sound subset of XML that is quite usable. Just like YAML, XML is hard to write correctly, but I would say the XML errors are much easier to spot. Both JSON and YAML have the problem of lacking tagged unions. Also, the XML data definition can be either extra complexity or a great tool depending on your usage. (But DTDs use an atrocious language either way.) None of those 3 standards have a really universal type representation, and while there are substandards for XML that extend the types, I've never seen anything that could encode even the C type system.

GoblinSlayer 5y ago
Yep, anything is hard to write. What's more important, YAML is hard to read, and it's by design as its markup was intended to be as invisible as possible.
- marcosdumay 5y ago
  Hum... JSON is quite easy to write. Too bad the lack of comments makes it unmaintainable. As the OP said, the quest for the perfect data language is still on.
  - GoblinSlayer 5y ago
    Hard to write as in you can botch it up. With JSON you need to be careful to close all the tiny braces, sometimes far apart.
- rishav_sharan 5y ago
  First time I have heard that YAML is harder to read compared to XML. XML might have many upsides over YAML, but readability isn't one of them
  - GoblinSlayer 5y ago

dehrmann 5y ago

> and is a frequent source of bugs Poor Norway. https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/

sinyug 5y ago

> I way prefer XML over something like YAML. So do I. XML is sane and has a lot of tooling readily available. YAML, with its significant white space, is one of the shittiest formats that I have ever encountered.

jdhawk 5y ago

https://json5.org/ https://json5.org/ comments. trailing commas

nigeltao 5y ago
JWCC (JSON With Commas and Comments) gives you exactly that, without other things that are arguably a mistake. https://nigeltao.github.io/blog/2021/json-with-commas-comments.html#why-not-json5-jsonc-1-hjson-or-hocon-instead https://nigeltao.github.io/blog/2021/json-with-commas-commen...
- fomine3 5y ago
  What VSCode use is JSONC, only allow comments https://github.com/microsoft/vscode/issues/100688 https://github.com/microsoft/vscode/issues/100688

paulddraper 5y ago

YAML is absolutely horrendous. What are the types in the following YAML document? a: true b: on c: yes d: TrUE e: aye It's as if the designers craved inconsistency.