4 ms·

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.

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.