Hacker News Reader

Comment by tofflos | Hacker News Reader

Am I the only one who finds YAML much harder to write than JSON or XML?

It's not just the fact that I get the syntax for lists and maps confused all the damn time. The worst part is that I'm unable to use the keyboard shortcut for automatically formatting my document!

I love that keyboard shortcut! I hate being without it! I'm certain it represents more than half of my key presses in other languages!

I type a few characters and then I press the code formatting shortcut. That's what I do! That's my workflow!

I don't understand how people who work in whitespace-significant languages can stand being without it! ;-)

(I'm only half-joking - I do find it very frustrating)

View on HN

JSON is a subset of YAML, so if you want to write YAML like JSON you can, and you can even automatically convert from JSON style to more idiomatic YAML, or vice-versa, with appropriate tooling.

Correction: YAML is a superset of JSON

To explain the downvotes: JSON ⊆ YAML implies YAML ⊇ JSON. You're saying the equivalent of "3 > 1 is wrong: 1 < 3".

What Drew is saying is absolutely correct though. YAML was specifically designed to be a superset of JSON. Conversely, when JSON was designed, YAML did not exist, so it only became a subset of YAML when the latter was introduced.

The words subset and superset do not imply any temporal relationship that somebody could get wrong.

The first time I heard that, I thought it was insane. I think it's still pretty insane.

That works if all your YAML authors are carefully avoiding any use of the features JSON can’t represent, like multiple documents, non-string map keys, and application-defined type tags.

> That works if all your YAML authors are carefully avoiding any use of the features JSON can’t represent, like multiple documents, non-string map keys, and application-defined type tags.

That's true if you want round-trip conversion to and from JSON, but you don't need that for automated round-trip conversion between JSON-style (delimited, or, in the language of the YAML spec “flow style”) YAML and the somewhat more idiomatic for most uses indented, (or, in the spec language, “block style") YAML, e.g., if you find it easier to edit in flow-style but you are in an environment that wants the end product delivered in block style.

Notably, whitespace sensitivity is a feature of block style, but not flow style.

despite how popular this claim is, it is not true.

The following is a valid JSON document according to the spec[1]:

  { "key": "value", "key": "otherValue" }

But is not a valid YAML document[2], something addressed in the spec itself. The JSON spec says

> The names within an object SHOULD be unique.

And `SHOULD` is defined by RFC 2119[3] as

> This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Also note that popular JSON validators exist which will accept the above example as completely valid[4]. Also note that Javascript's JSON.parse[5] will accept the above as valid, as does JavaScript itself for object keys (which, yes, is not JSON).

Yes, I know about RFC 8259 vs ECMA 404. The real world examples noted above, though, speak for themselves.

[1] https://tools.ietf.org/html/rfc4627

[2] https://yaml.org/spec/1.2/spec.html

[3] https://tools.ietf.org/html/rfc2119

[4] https://www.freeformatter.com/json-validator.html

[5] https://www.ecma-international.org/ecma-262/#sec-internalize...

Hey dimitri, what's up.

JSON is not 100% a subset of YAML, this is true; that's slightly a simplification of the truth that is commonly echoed. It is a syntactically a subset of YAML, and for anything representable in JSON you can still do a functionally-lossless translation* from JSON to YAML and back again. This is because:

> In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten.

So,

    { "key": "value", "key": "otherValue" }

becomes

    { "key": "otherValue" }

in a round trip, but represents the same thing, going by ECMA262 rules.

These are definitely distinct snippets of JSON and if you only use RFC4627 then it doesn't define anything about how to parse the JSON beyond the syntax, whereas the YAML spec is a bit more complete in regards to specifying semantics probably partly since it's a more complicated language. Thankfully in the common case most JSON parsers do as specified in ECMA262 (which makes sense since that's where this format came from anyways) and use the latest key. You can see this in Go's "encoding/json" for example. So this property is still meaningfully true, I'd argue, even if it is more nuanced than commonly believed.

tl;dr: It is true that not all valid JSON is valid YAML. However, automatic translation between the JSON and YAML is still possible if you are going by ECMA262 JSON semantics.

P.S.: In practice, YAML parsers do actually often take the liberty of interpreting YAML to be a proper superset. This isn't too surprising since most YAML parsers take a lot of liberties that are/were outright spec violations, but just as an example, here's PyYAML:

    >>> from yaml import load
    >>> load('{"a":"1","a":2}')
    {'a': 2}

When I read this, I didn't believe it. I needed to prove this to myself!

I've seen and used YAML files for configurations in many places and I've always found editing YAML files by hand too much of a pain. It's very easy to miss a space and screw everything up. However, writing JSON directly into a plain text file is totally easy.

So, I created a normal text file named 'array_of_objects.json' like this -

  [
   {
    "first": "one"
   },
   {
    "second": "two"
   }
  ]

And then I wrote a ruby program to read it -

  require 'json'
  require 'yaml'
  
  array_of_objects = YAML.load_file 'array_of_objects.json'
  p array_of_objects

And I see the output as -

  [{"first"=>"one"}, {"second"=>"two"}]

I still can't get over it. I'm thinking of the countless hours wasted!!

Thank you so much.

Not me, I love YAML. I even write my content like blogs and such in raw YAML!

Not alone, my preference goes to XML, and JSON second.

So far I have been mostly YAML safe and will try to keep it that way, but it is getting hard when having to deal with k8s.

My keyboard shortcut for automatically formatting my documents usually understand the document format or programming language I'm using.

If it doesn't then I'm using the wrong editor.

The problem is that in YAML, white space is significant. How is a formatted supposed to know:

    key1: value1 key2: value2

...is supposed to be:

    key1: value1
    key2: value2

? How is it supposed to know if the first is actually what you meant to write?

In grammars that aren’t white space dependent (such as JSON), it’s clear what this means:

    { "key1": "value1", "key2": "value2" }

Significant whitespace seems like a good idea and looks great in small examples but it has some very serious downsides in real use. Being able to reliably reformat hundreds of lines of code with a single keypress is far more valuable than a few saved braces.

But it hasn’t hurt Python popularity.

Personally it’s one of reasons I’m using python less and less and JavaScript more and more. I just can’t stand the white space.

The difference between Python and YAML is that Python doesn't have a semantically-equivalent, non-indentation-sensitive presentation style. How you choose to view and work with YAML is a choice that doesn't need to have any impact on what you share with others and how they choose to view and work with it.

While I'm not usually fond of “you're holding it wrong” arguments, that's pretty much the proper response to complaints about YAML’s indentation sensitivity, since you can work with YAML in a style which isn't indentation sensitive without anyone you share data with seeing anything different.

It's possible that Python might be more popular than it is without this feature. It's certainly one of the main reasons I avoid it.

Python’s grammar is well defined and has far more validation. YAML has multiple ways to define the same output and since it makes almost anything legal there’s not a way for a tool to disambiguate.

For example, if you double-indent something, YAML will just silently assume you wanted a nested data structure but Python will throw an indentation error. That causes issues in many editors when copy-and-pasting.

That pattern continues where Python uses indentation to force clarity and consistency but still has syntax which removes ambiguity. A key one is that Python requires quoting data, avoiding all of the common data loss in YAML when people happen to enter data with meaning in YAML (country=no, names with equal signs or colons, etc.), and you have to open and close structures with syntax rather than just indentation.

The most analogous Python bug is when a statement immediately after an if, nested def, etc. is one level of indentation than intended. That definitely happens but a fair fraction of the time it’s immediately obvious because it usually fails due to something like a variable not being in scope. YAML consumers are more likely to ignore extra elements so it’s easier to miss things like that for a while unless you have an unusually strict validation stage.

> Significant whitespace seems like a good idea and looks great in small examples but it has some very serious downsides in real use.

In some contexts, sure, which is one reason why YAML has two presentational styles with equal semantic power, between which a suitable tool can convert mechanically, and only one of those two styles features whitespace sensitivity.

> Being able to reliably reformat hundreds of lines of code with a single keypress is far more valuable than a few saved braces.

YAML gives you the ability to freely switch between a presentational style which provides the former and one which provides the latter, with no loss of semantic power, so it doesn't really matter which is better, since you don't have to choose between one and the other.

If Python & Haskell had this I'd be more inclined to use both of them.

> If Python & Haskell had this I'd be more inclined to use both of them.

Haskell does.

https://en.m.wikibooks.org/wiki/Haskell/Indentation

Yes, in whitespace significant languages whitespace is significant. I could complain that my editor doesn't figure out how to fix all of my braces if I hit a button, after all I got the indentation right and can visually see the structure of my code should be correct no sweat.

The issue is that in practice it’s quite difficult to reliably get whitespace correct all of the time, whereas braces seem quite easy to get right. If you’ve ever tried cutting and pasting a code block in python you know the pain of having to manually fix whitespace. The same operation in a brace-delimited language has a much smaller chance of going wrong, as the only thing you need to get right is the endpoints of the cut selection.

{ "key1": values, “key2”: value2 } is valid YAML with the same sematics as it has in JSON; if you have a YAML-aware editor (or editor mode) it will probably format that just as easily as in JSON.

If you write

    { "key1": "value1", "key2": "value2" }

without the commas, you're also on your own when it comes to fixing it.

You just type [enter] instead of [space] between "value1" and "key2:" in your original example to get correct indentation.

Reply on news.ycombinator.com