Hacker News Reader

Comment by dissent | Hacker News Reader

I reckon if this is really a big concern for anybody, then they are probably writing way too much YAML to begin with. If you're being caught out by things like this and need to debug it, then it maps very cleanly to types in most high level languages and you can generate your YAML from that instead.

View on HN

Sadly you usually realize you've been writing too much YAML way past the turning point, and it will be a pain to move a single file to JSON for instance when you have a whole process and system that otherwise ingest YAML, including keeping track of why this specific part of JSON and not YAML.

So people work around the little paper cuts, while still hitting the traps from time to time as they forget them.

> generate YAML

I've a hard time finding a situation where I'd want to do that. Usually YAML is chosen for human readability, but here we're already in a higher level language first. JSON sounds a more appropriate target most of the time ?

There are probably two use cases.

Configuration files for programs. These tend to be short.

DSLs which are large manifests for things like cloud infrastructure. These tend to be long, they grow over time.

My pet hypothesis is these DSLs exist mostly for neutrality - the vendor can't assume you have Python or something present. But as a user, you can assume just that and gain a lot by authoring in a proper language and generating YAML.

See https://github.com/cloudtools/troposphere for a great example for AWS CloudFormation.

> Configuration files for programs. These tend to be short.

This is where I use YAML and it shines there. IMO easier to read and write by hand than JSON, and short sweet config files don't have the various problems people run into with YAML. It's great.

I can't run the examples right now, but looking at the last "print(template.to_json())" line, looks like the main use case is JSON ?

On cloud infra, yes, having one or two layers of languages is a natural situation. GCP and AWS both accepting (encouraging?) JSON as a subset of YAML makes it a simpler choice when choosing an auto generating target.

You mention people wanting to author the generated files, I think in other situations tweaking the auto-generated files will be seen as riskier with potential overwriting issues, so lower readability will be seen as a positive.

That's the point really, you can generate JSON or YAML and it doesn't really matter. If you want to include 100 similar objects in that output, you can use a for loop. You can't do that in plain JSON/YAML.

Isn’t yaml a strict superset of JSON? Any compliant YAML parser should be able to ingest a JSON document.

Are there no cases where well-formed JSON could be subject to the problems covered in the article, when parsed by a compliant YAML parser? I'm asking because I know nothing about YAML and not much more about JSON.

Not that I know. JSON requires strings to be quoted which is basically the problem here. Of course it’s not a great human writable configuration format (no comments being a huge problem).

I’m just pointing out that it should be very simple to swap a YAML file for a JSON file in any system that accepts YAML

JSON is stricter than YAML so that class of issues is avoided.

Yes. Rewriting a YAML file into strict JSON won't have any impact on the ingestion or the processing of it.

https://metacpan.org/pod/JSON::XS#JSON-and-YAML

> I have been pressured multiple times by Brian Ingerson (one of the authors of the YAML specification) to remove this paragraph, despite him acknowledging that the actual incompatibilities exist. As I was personally bitten by this "JSON is YAML" lie, I refused and said I will continue to educate people about these issues, so others do not run into the same problem again and again. After this, Brian called me a (quote)complete and worthless idiot(unquote).

> In my opinion, instead of pressuring and insulting people who actually clarify issues with YAML and the wrong statements of some of its proponents, I would kindly suggest reading the JSON spec (which is not that difficult or long) and finally make YAML compatible to it, and educating users about the changes, instead of spreading lies about the real compatibility for many years and trying to silence people who point out that it isn't true.

> Addendum/2009: the YAML 1.2 spec is still incompatible with JSON, even though the incompatibilities have been documented (and are known to Brian) for many years and the spec makes explicit claims that YAML is a superset of JSON. It would be so easy to fix, but apparently, bullying people and corrupting userdata is so much easier.

Well that’s disappointing.

This explains some things on, like, a mythic level, that I’ve felt about yaml practically since the first time I saw it.

I guess software are human texts after all.

True. YAML is an intermediate representation between my intention expressed in Dhall and what runs in production.

https://github.com/dhall-lang/dhall-kubernetes

Reply on news.ycombinator.com