Hacker News Reader

Comment by jfaucett | Hacker News Reader

    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?

View on HN

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.

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.

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.

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

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.

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.

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.

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

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

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

In TOML:

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

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

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

One which happens to also work for YAML.

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

The problem is in the semantics

Please add the s-expr version?

Reply on news.ycombinator.com