Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fear and Loathing in YAML

chrisshort.net

Post reply on HN
Print view View original

91–100 of 107 posts

Re: Fear and Loathing in YAML

#91

Post by acdha »

goatlover wrote: post #68
cageface wrote: post #53

Earlier quoted context omitted.

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.

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.

Re: Fear and Loathing in YAML

#92

Post by HelloNurse »

Today I edited a Docker Compose YAML configuration file. The network configuration has "ports" sections, such as

  ports:
    - "8080:80"
Which (assuming some other network configurations) means that whatever answers to port 80 in the container can be reached at port 8080 of the host running Docker.

Simple syntax and straightforward semantics, but port numbers are integers: why strings? Because, as the Docker manual warns, YAML is clever.

> When mapping ports in the HOST:CONTAINER format, you may experience erroneous results when using a container port lower than 60, because YAML parses numbers in the format xx:yy as a base-60 value. For this reason, we recommend always explicitly specifying your port mappings as strings.

Re: Fear and Loathing in YAML

#94

Post by jerf »

doteka wrote: post #85
ben-schaaf wrote: post #74

Earlier quoted context omitted.

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.

Re: Fear and Loathing in YAML

#95

Post by pjbk »

brown9-2 wrote: post #15
pjbk wrote: post #2

Looking back to the last decade, I cannot remember a single project I worked in that relied on YAML that didn't have at least one incident from its users or developers dealing with the files and messing up. Just some months ago a team I was working with lost almost a day on a misbehaving software module. After serious detective work it all came down to whitespace in a YAML configuration file. I remember being pretty…

I’m curious, do you recall what the specifics of the whitespace change were?

Yes. It was an indentation issue. It turned that the parent list accepted an item with the same id, so it was a valid statement and the full thing seemed OK. However the data ended up missing from where it was supposed to be.

Re: Fear and Loathing in YAML

#96

Post by pjbk »

predakanga wrote: post #48
pjbk wrote: post #2

Looking back to the last decade, I cannot remember a single project I worked in that relied on YAML that didn't have at least one incident from its users or developers dealing with the files and messing up. Just some months ago a team I was working with lost almost a day on a misbehaving software module. After serious detective work it all came down to whitespace in a YAML configuration file. I remember being pretty…

Have you considered validating your YAML against a schema? JSON Schema[0] can do the trick, and has decent editor support[1]. It's not a panacea, but it can help avoid those long debugging sessions. [0]: https://json-schema-everywhere.github.io/yaml [1]: https://marketplace.visualstudio.com/items?itemName=redhat.v...

Thanks for the suggestion. Last time I had to use YAML I used StrictYAML instead which gave me more peace of mind. I knew that there were schema tools around, however I just put more checks in the validator to avoid adding extra dependencies. Next time I will definitely look into those.

Re: Fear and Loathing in YAML

#97

Post by dimitropoulos »

dragonwriter wrote: post #52
tofflos wrote: post #39

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 cha…

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.

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...

Re: Fear and Loathing in YAML

#98

Post by jjtheblunt »

dnautics wrote: post #61
jjtheblunt wrote: post #40

Amazon's Ion format is decent, albeit not so long in the public domain, i believe

wow, thanks for that. Ion is really pretty. But I still can't shake it that curly brace delimiters are inappropriate for a configuration format.

I think that a subset of Ion is exactly JSON, so it gets that curly brace notation as a previous choice from the Javascript world.

Re: Fear and Loathing in YAML

#99

Post by dragonwriter »

jjtheblunt wrote: post #98
dnautics wrote: post #61

Earlier quoted context omitted.

wow, thanks for that. Ion is really pretty. But I still can't shake it that curly brace delimiters are inappropriate for a configuration format.

I think that a subset of Ion is exactly JSON, so it gets that curly brace notation as a previous choice from the Javascript world.

A subset of YAML is exactly JSON, but you very visibly don't have to use curly brace notation with it.

Re: Fear and Loathing in YAML

#100

Post by tieske »

Like perl is a "write-only" language, YAML is a "read-only" format. Humans should not be manually editing YAML, there are way too many caveats. (my favorite being the country code for Norway "NO" being a boolean-false, if not quoted)
Post reply on HN