Hacker News Reader

Comment by creshal | Hacker News Reader

What's the difference to / advantage over YAML? When I want a loose syntax "JSON with comments", I can just use that instead.

View on HN

> YAML expresses structure through whitespace. Significant whitespace is a common source of mistakes that we shouldn't have to deal with.

> Both HOCON and YAML make the mistake of implementing too many features (like anchors, sustitutions or concatenation).

But this too has significant whitespace, acting as a comma in separating properties. (It's not clear whether you can mix commas and whitespace here.)

Also this claims to not need escapes, but it's also not clear how this format handles a comma or a newline in strings without escaping, do they act as a comma to separate properties or do they act as natural commas/newlines?

Only quoteless strings have no escapes, and according to the docs the rule is:

  > quoteless strings include everything up to the end of the
  > line, excluding trailing whitespace.

(edit: formatting)

So this

{

  foo:one,

  bar:two

}

Parses to "one," because it is a quoteless string?

What about true and false, is false the boolean constant or a unquoted string "false".

I posted this in another thread here, but it's documented in the linked page:

  > A value that is a number, true, false or null in JSON is parsed as a value.
  > E.g. '3' is a valid number while '3 times' is a string.

>YAML make the mistake of implementing too many features (like anchors, sustitutions)

That's why I remove those features.

Significant whitespace is a normal complaint for beginners in python too, but most people prefer it in the end.

A point against YAML, that I always read, is its specification, too big etc. I don't know much about this issue...

I like how nice config files can look with YAML and JSON being a subset of it makes it even more convenient

HJSON isn't exactly a nicely compact spec I'd want to use in data exchange either. For local configuration files and the likes, where you want comments etc., it doesn't really matter how big the spec is.

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

JSON spec: http://www.ecma-international.org/publications/files/ECMA-ST...

If you haven't read the JSON spec and you use JSON I recommend doing so. It takes five minutes. My personal favorite line: "Because it is so simple, it is not expected that the JSON grammar will ever change."

I did, long time ago.

Also, they're probably right. I mean JSON isn't pretty, but its easy. Why should I use YAML for prettier config files, when the people looking into those files are all technical anyway.

Reply on news.ycombinator.com