No: Body: Wants: To: Write: – YAML | Hacker News Reader

No: Body: Wants: To: Write: – YAML

noyaml.com

66 pointsghuntley71 comments

    No:
	Body:
		Wants:
			To:
				Write:
					- YAML

vs.

    <No>
        <Body>
            <Wants>
                <To>
                     <Write>
                         <item>YAML</item>
                     </Write>
                </To>
            </Wants>
        </Body>
    </No>

vs.

    {
       "no" : {
          "body" : {
              "wants" : {
                 "to" : {
                    "write" : [ "YAML" ]
                  }
               }
           }
       }
    }

Which would you rather write?

(No (body (wants (to (write ‘(yaml))))))

It's a bit of a strawman, since none of your examples actually resemble valid config files and you're forcing them all to have the same indentation, when significant whitespace only matters in YAML.

That, not too mention how often do you actually write data files by hand? Maybe a small sample file for testing, but beyond that all data is going to be read in from files or come from an API.

JSON is not bad to write by hand. Simple XML isn't too bad either, but I still prefer JSON.

This discussion seems to be largely about configuration files. Those usually are written and maintained by hand.

JSON doesn't have comments. If I want to know why a config has a particular value, I can write a comment to explain it in YAML or xml, just like I would do in code. Lack of comments is the primary reason I would not use json for anything that needs to be written or read by humans.

none of your examples actually resemble valid config files

Neither does the YAML one? So?

you’re forcing them all to have the same indentation

I don’t know about you, but I always pretty-print JSON, just like I always indent my code no matter which language I’m using.

In fact that’s one of the arguments in favour of significant whitespace -- you’re going to be indenting anyway, so why bother with the brackets? It’s not an argument everyone buys, but everyone still indents their code.

> you’re going to be indenting anyway, so why bother with the brackets?

Because brackets are explicit. Whitespace is implicit and difficult to distinguish without editor support.

I did say not everyone buys it! :)

More seriously, the earlier comment complained that the indentation for the non-significant-whitespace examples was artificial. I’m saying it’s not artificial because in practice you would indent it.

Oh yeah I agree on that front entirely, I just wanted to comment on the other piece.

> > you’re going to be indenting anyway, so why bother with the brackets?

> Because brackets are explicit. Whitespace is implicit and difficult to distinguish without editor support.

I'm with parent on this one. Most people who complain about python's reliance on indentation still indent their code, and rely on the visual & editor hints (ie. they're profoundly confused when they muck up their indentation, but their brackets are still correct).

But I digress.

Whitespace is explicit in some (markup) languages, and there's nothing *plicitly wrong with that. If you're trying to do any kind of editing of a (markup) language that relies on sensible indentation with an editor that doesn't understand whitespace then you've probably got bigger problems.

> Whitespace is explicit in some (markup) languages, and there's nothing plicitly wrong with that.*

Whitespace is never explicit. It only exists as the gap between other characters. You only perceive its absence.

> If you're trying to do any kind of editing of a (markup) language that relies on sensible indentation with an editor that doesn't understand whitespace then you've probably got bigger problems.

Which is why they should not be used for configuration files.

In TOML:

  nobody.wants.to.write = [ "YAML" ]

My preference:

    # I guess you could put ["YAML"] if you need it as an array and not a string
    no.body.wants.to.write=YAML

Easy to type, is on a single line, only breaks once you're so many layers deep that you need to scroll horizontally - but let's be real - if that happens the config isn't the problem but why is your program so complex? is the problem.

Drawbacks of this are when the program is inconsistent. Was it `nobody.wants.to.write` or `no.body.wants.to.write`? Or alternatively, why is it `nobody.wants.to.read` but `no.body.wants.to.write`?

> why is it `nobody.wants.to.read` but `no.body.wants.to.write`?

Made me think there's also a big difference in what nobody prefers reading vs. what nobody prefers writing.

{"no":{"body":{"wants":{"to":{"write":["YAML"]}}}}}; // A one-liner.

One which happens to also work for YAML.

Invalid JSON though, due to the semi-colon and the comment.

The problem is in the semantics

Shameless plug: I've been toying with a "format-agnositic jq" for all of these object like formats: https://github.com/jzelinskie/faq

Here's an interesting example of using bencode which is the object format for BitTorrent:

      curl -sL https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/debian-9.4.0-amd64-netinst.iso.torrent | faq -f bencode 'del(.info.pieces)' -o json
      {
        "announce": "http://bttracker.debian.org:6969/announce",
        "comment": "\"Debian CD from cdimage.debian.org\"",
        "creation date": 1520682848,
        "httpseeds": [
          "https://cdimage.debian.org/cdimage/release/9.4.0//srv/cdbuilder.debian.org/dst/deb-cd/weekly-builds/amd64/iso-cd/debian-9.4.0-amd64-netinst.iso",
          "https://cdimage.debian.org/cdimage/archive/9.4.0//srv/cdbuilder.debian.org/dst/deb-cd/weekly-builds/amd64/iso-cd/debian-9.4.0-amd64-netinst.iso"
        ],
        "info": {
          "length": 305135616,
          "name": "debian-9.4.0-amd64-netinst.iso",
          "piece length": 262144
        }
      }

Please add the s-expr version?

The last one to be honest. It's comforting in a way.

I want to write YAML because I don't want my configuration to look significantly different in go, java, ruby, or any other language my organization may use in the future.

Xml is fine. Json is fine. Yaml is fine. Yes, they have warts. That's fine too.

None of the languages mentioned are whitespace sensitive or look much like YAML at all.

For most things lately I've been using TOML because it gets me that, and it's a relatively simple (to a human) standard. Combined with there being parsers and emitters in just about every language now, it's a great option. You get sections in the config that map easily to native data structures in the languages, good string handling, can create a few more advanced things like arrays (really useful for adding multiple ports or listening addresses, etc.).

I do still use YAML on the rare occasion where i just don't like how the TOML ends up looking[1]. My plan with that example is to eventually make a more simplist DSL that can handle the usecase, but my first attempts didn't produce anything I liked.

[1] https://github.com/perlbot/App-EvalServerAdvanced/blob/maste...

I like YAML. It's ok if you don't. It's ok that I do. Want to use TOML? Awesome. Want to use JSON? Go for it. I prefer YAML, it works for me and I'll keep using it until something better comes along that I like.

Preference is preference. Stop acting like it's not. This page might have been "Nobody wants to use VI" or "Nobody wants to use Emacs" or "Nobody wants to use [insert thing I hate here]"

With Emacs vs VI we have a choice.

Kubernetes...devops tooling...CloudFormation?

You better <3 YAML.

So lobby those projects to add more support. Heck, make a PR to add the serialization language of your choice. Start coding. If they don't want patches for "[insert data serialization formation here]", maintain your own fork.

FWIW CloudFormation added YAML, which was a vast improvement to usability IMO over where they started. Want CloudFormation to support something else? Lobby through your AWS account rep for what you want supported.

I agree with what you are saying but the boat has sailed. Just like decisions with the SMTP protocol in the early years where folks can fake the FROM field thus causing the issues we experience every day the same is true with devops and yaml. Forever:Drowning:In-YAML.

CloudFormation supports json too. And if you really want to use json for docker or kubernetes you can use a yaml cli. `docker-compose up -f <(npx js-yaml docker-compose.json)` or something like that.

Requires Javascript to even start showing the text. That "live" editor trick is neat, but pretty unnecessary to transmit the message, if you ask me. Also there are some good-old links that are not even clickable. Weird choice of tool for the job.

Just as YAML provides no validation document, intellisense or type safety this website is designed to be a hindrance. It's part of the message to make the experience more real. I do accept PRs tho so mash the octocat.

Challenge.

> We replaced 1,000 lines of YAML with 10 structs ...

I looked, but target URL didn't spell it out, and I lack sufficient domain knowledge to dive into the repo to find it -- but I'm curious as to how big, and indeed how complex, those 10 structs are.

It seems disingenuous to swap units mid-sentence when comparing size or complexity.

My gut feel is the set of people who could understand thoughtfully designed YAML should be larger than the set of people who could understand thoughtfully designed structs (+ wrappers?).

This quote was taken from a kubernetes retrospective at https://about.sourcegraph.com/go/valuable-lessons-in-over-en...

Scroll to the bottom:

In a nutshell, they got rid of a custom programming language they had inadvertently created via YAML and text/template. Their YAML models were effectively written in a Turing-complete language composed of YAML and text/template directives. They had been heavily abusing the FuncMap type in text/template.

Thanks, and yes, I did read through that page. Lots of coloured text that tantalisingly looked like links but weren't, and a lot of broken images/slides.

I got to https://github.com/kubernetes/kops ... and that's where I got out of my depth.

It sounds like it wasn't a problem with YAML per se, but their misappropriation of text/template and wrangling YAML to be something other than a configuration tool. It feels similar to if I were to complain about the shortcomings & complexity of the jinja2 constructs I make within my YAML.

Ah yes but please revisit this problem space from the perspective of a consumer of YAML. Ops folks are drowning in it. The industry can and should do better.

YAML is not 100 percent awesome, but it's machine consumable, not too hard to edit by hand, and preferable (in my opinion) to a plethora of application specific DSLs with different requirements for curly braces, semicolons and assignment operators.

I always struggle to write YAML. I still don't know how the '-' things work and what level of indentation to use for its children.

My go-to tool to see what yaml will look like. http://nodeca.github.io/js-yaml/

One of the lovely bits I ran into recently is whether a given YAML parser interprets a value as a string or not (for example) is entirely up to the parser, and there's nothing you can really do about it in the syntax. Quoting is a useful hint, but the parser doesn't have to take action as a result. !!str is another useful hint, but str is kind of up to the parser. My favorite related bug that shows the kind of shenanigans that simply using YAML results in: https://github.com/kubernetes/helm/issues/1707

Did I read correctly that YAML is a superset of JSON?

> This means that, in theory at least, a YAML parser can understand JSON

Does anyone have experience with this? It seems counter-intuitive at first, but Google agrees, and I don't know enough about parsers to say it's wrong. Can you really feed pretty much any JSON file into a YAML parser and get back a valid and correct, properly formed data structure?

The explicit goal of yaml 1.2 was to fix up any incompatibilities with json.

http://yaml.org/spec/1.2/spec.html

Yes, the only problem I have encountered was some version of pyyaml that couldn't deal with \t characters (which are valid in JSON but not YAML 1.1, 1.2 fixed this).

This site is unusable on mobile. I can't even follow the links.

Same. Ghostery on Android

The links don't work on desktop, either. It isn't a mobile thing.

The links are:

https://tinyurl.com/lessons-in-over-engineering and https://twitter.com/ellism/status/1008728148131733504

I accept accessibility PRs. Mash the octocat.

Dear god the unnecessary emojis as well. Why?

I don’t need a “thought” emoji to read your first line, I don’t need the finger pointers to see where I should read next, it’s condescending and terribly ugly.

Because it's an emotional rant that was shipped in <15mins. It's not designed to please. It's designed (inc UX of a code editor) to be an over the top 'too close to reality' realistic experience for any engineer in the devops arena.

PS: I accept PRs to make it work better on mobile including accessibility. Send PRs.

Earlier Related Post: https://news.ycombinator.com/item?id=17358103

YAML's like democracy: it's the worst option aside from all the others.

That said, I'm partial to s-expressions and TOML nowadays.

I love YAML and I don't care what anyone else thinks. For simple config files, I use INI (could use TOML, I suppose). For anything beyond that, I use YAML. It's easy to read, parse, write, and maintain. I just use the subset that's relatively straightforward (no & ! --- sigil vomit).

Here's someone who really has been hurt by YAML. I've never used it but it's good to know to steer clear in case I encounter it as an option.

There is literally no way to click those links on an Android phone. They're not clickable and I can't even highlight them to copy and paste.

I've never liked YAML. It's one of the things that turned me off from Swagger. It's incredibly ugly and overly complex.

use it almost every day. it's an ugly little notation with super-limited utility, but when JS gets its act together, we can finally abandon it forever.

What a stupid argument that is not worth the time.

This website is a little too dope for me.

Or: Read: It:

What is this, bag-on-YAML day at HN?

I am really beginning to hate programmer-centric tooling. It has turned all of us into these miserable, cretinous engineering snobs. It seems impossible for anyone to contemplate why people would choose to work differently than them. Zero empathy. Fucking pathetic.

Make software hard again, I say. Treat the compiler like you would treat your dominatrix. Life would be so much better that way!

At least the other link was a clear, well-written, well-reasoned article. I have no idea what this one is.

It's a silly rant about feelings. Spin up a decent sized Kubernetes cluster or use CloudFormation and please report back how you feel 6 months later.

Kubernetes grew out of Borg, right?

Ever use borgcfg?

Nah. Can you reference any public examples of an example cfg out in the wild?

The first google hit I get is a presentation that includes a very small config sample: http://www.hpts.ws/papers/2015/wilkes.pdf

The second hit is a google+ post wailing “arrrrgh, somebody reinvented borgcfg for Kubernetes” :)

I’m guessing the switch to YAML, even though it might be a bit tedious, was an explicit reaction to the fact that the ultra-programmable borgcfg turned out to cause some big headaches.

I'm with you on this one. I enjoyed reading the arp242 article, but this one's like a bad meme - an incomprehensible mish-mash of links and emojis.

Not to mention fatal JS errors on mobile.

bag-on-on-YAML-and-provide-no-useful-alternatives day

HCL is pretty good

HOCON, from the Scala community, is great. It’s specifically designed for configure files (as opposed to data transfer) so has a bunch of features that make that easier.

Reply on news.ycombinator.com