8 ms·

I generally dislike languages like YAML or Python where whitespace matters, and can break your code, however, YAML is way more easily human readable than JSON,

I generally dislike languages like YAML or Python where whitespace matters, and can break your code, however, YAML is way more easily human readable than JSON, so I started to appreciate it for readability purposes. I guess YMMV, but after you've used both YAML and JSON for a while, you might appreciate YAML a little bit more.

chriswarbo 8y ago
> YAML is way more easily human readable than JSON, so I started to appreciate it for readability purposes. > I guess YMMV, but after you've used both YAML and JSON for a while, you might appreciate YAML a little bit more. I've used JSON a lot, and XML and s-expressions and MessagePack and ini and YAML and a whole bunch of other formats. I usually have to fire up Google to read YAML. YAML is the only one where I routinely have to Google for a syntax cheatsheet and wade through tables of redundancy and edge-cases. YAML made sense before JSON became a thing. Why people persist with it in new projects is baffling to me.
- ekianjo 8y ago
  a raw YAML file is readable with your eyes. A Json file needs to be prettified before you go thru it. Json is good for APIs but is not made for readibility.
  - chriswarbo 8y ago
    We must disagree with what "readable" means then. I find JSON readable (as long as it's nicely layed out, e.g. by piping through 'jq "."'), in the sense that I can skim over the structure looking for [/]/{/}/". If I want to read some of the content, like a string, I just need to read '\"' as '"' and '\\' as '\', which is a small constant cost per (usually rare) occurrence. With YAML it's difficult to even know the structure of what I'm looking at, due to anchors and extensions. It's also hard to discern structure from skimming, since strings can appear unquoted, and may contain unescaped lexical tokens (depending on which particular symbols it started with); hence we must carefully consider each and every character, rather than just skimming for the next token. If I know I'm looking at a perfect YAML file, than I should be able to guess the gist of what it says, since I can make assumptions about what the syntax means. If I want to be sure, I'd be Googling for cheatsheets. Yet as a programmer, I mostly look at files when they're buggy, meaning I can't just assume that, say, an unescaped quotation mark won't terminate the string; or that a certain piece of text is allowed to run across multiple lines; or that the indentation corresponds to the nesting; etc.
    - thanatropism 8y ago
      That's what syntax highlighting is for. I use notepad++ for YAML. Besides coloring what it thinks I'm thinking, it displays vertical lines corresponding to the indentation levels. (I prefer INI/TOML whenever I can help it; hierarchies in TOML are so counterintuitive that it incentivizes a simple flat structure. But then, some things are irremediably hierarchical)
  - basil-rash 8y ago
    Is it really though? The implicit typecasting gives rise to very unexpected results, that you'd never get with JSON. See: https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/
bamboozled 8y ago
The killer feature for me over JSON is comment support, it's definitely useful to add todo comments etc.
- abraae 8y ago
  Yep, so true. Any decent config file that will be seen/edited by a human needs comment support. And any file that will not be seen by a human could be json (or whatever).
- krferriter 8y ago
  Yeah this is a huge selling point of YAML. JSON should have comments added to the spec. The other benefit to YAML is human readability, which is usually better in YAML compared to JSON. A specific glaring example of this is when there are long string-literal snippets inside the document, in YAML this is massively more readable than in JSON.
  - hannasanarion 8y ago
    JSON shouldn't have comments added to the spec, because people shouldn't be trying to read or write JSON. It's an application interchange language, meant to be written and read by machines. YAML is a markup language, meant to be written and read by people. Ever notice how most YAML libraries don't even have a "dump" function?
    - krapp 8y ago
      >It's an application interchange language, meant to be written and read by machines. Not entirely true, JSON is based on Javascript objects, it was meant to be written and read by humans just like Javascript, INI or any other basic serialized data format, or text-based programming language. If JSON were truly never meant to never be viewed or edited by human beings, it would have been published as bytecode.
    - heavenlyblue 8y ago
      >> Ever notice how most YAML libraries don't even have a "dump" function? No. I guess unless you’re using something half-baked, I suppose. Machines need to be able to edit configs either way.
h1d 8y ago
Have you considered alternatives like TOML or JSON5?

chriswarbo 8y ago

> YAML is way more easily human readable than JSON, so I started to appreciate it for readability purposes. > I guess YMMV, but after you've used both YAML and JSON for a while, you might appreciate YAML a little bit more. I've used JSON a lot, and XML and s-expressions and MessagePack and ini and YAML and a whole bunch of other formats. I usually have to fire up Google to read YAML. YAML is the only one where I routinely have to Google for a syntax cheatsheet and wade through tables of redundancy and edge-cases. YAML made sense before JSON became a thing. Why people persist with it in new projects is baffling to me.

ekianjo 8y ago
a raw YAML file is readable with your eyes. A Json file needs to be prettified before you go thru it. Json is good for APIs but is not made for readibility.
- chriswarbo 8y ago
  We must disagree with what "readable" means then. I find JSON readable (as long as it's nicely layed out, e.g. by piping through 'jq "."'), in the sense that I can skim over the structure looking for [/]/{/}/". If I want to read some of the content, like a string, I just need to read '\"' as '"' and '\\' as '\', which is a small constant cost per (usually rare) occurrence. With YAML it's difficult to even know the structure of what I'm looking at, due to anchors and extensions. It's also hard to discern structure from skimming, since strings can appear unquoted, and may contain unescaped lexical tokens (depending on which particular symbols it started with); hence we must carefully consider each and every character, rather than just skimming for the next token. If I know I'm looking at a perfect YAML file, than I should be able to guess the gist of what it says, since I can make assumptions about what the syntax means. If I want to be sure, I'd be Googling for cheatsheets. Yet as a programmer, I mostly look at files when they're buggy, meaning I can't just assume that, say, an unescaped quotation mark won't terminate the string; or that a certain piece of text is allowed to run across multiple lines; or that the indentation corresponds to the nesting; etc.
  - thanatropism 8y ago
    That's what syntax highlighting is for. I use notepad++ for YAML. Besides coloring what it thinks I'm thinking, it displays vertical lines corresponding to the indentation levels. (I prefer INI/TOML whenever I can help it; hierarchies in TOML are so counterintuitive that it incentivizes a simple flat structure. But then, some things are irremediably hierarchical)
- basil-rash 8y ago
  Is it really though? The implicit typecasting gives rise to very unexpected results, that you'd never get with JSON. See: https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/

bamboozled 8y ago

The killer feature for me over JSON is comment support, it's definitely useful to add todo comments etc.

abraae 8y ago
Yep, so true. Any decent config file that will be seen/edited by a human needs comment support. And any file that will not be seen by a human could be json (or whatever).
krferriter 8y ago
Yeah this is a huge selling point of YAML. JSON should have comments added to the spec. The other benefit to YAML is human readability, which is usually better in YAML compared to JSON. A specific glaring example of this is when there are long string-literal snippets inside the document, in YAML this is massively more readable than in JSON.
- hannasanarion 8y ago
  JSON shouldn't have comments added to the spec, because people shouldn't be trying to read or write JSON. It's an application interchange language, meant to be written and read by machines. YAML is a markup language, meant to be written and read by people. Ever notice how most YAML libraries don't even have a "dump" function?
  - krapp 8y ago
    >It's an application interchange language, meant to be written and read by machines. Not entirely true, JSON is based on Javascript objects, it was meant to be written and read by humans just like Javascript, INI or any other basic serialized data format, or text-based programming language. If JSON were truly never meant to never be viewed or edited by human beings, it would have been published as bytecode.
  - heavenlyblue 8y ago
    >> Ever notice how most YAML libraries don't even have a "dump" function? No. I guess unless you’re using something half-baked, I suppose. Machines need to be able to edit configs either way.

h1d 8y ago

Have you considered alternatives like TOML or JSON5?