Live data from Hacker News

YAML: probably not so great after all (2017)

arp242.net

291–300 of 412 posts

Re: YAML: probably not so great after all (2017)

#291

Earlier quoted context omitted.

I totally agree that in the ideal world, JSON should support comments. I yearn for them, and none of the in-band work-arounds or post-processing tools are acceptable substitutes. But to play the devil's advocate, how would JSON be able to support round-tripping comments like XML can, since are part of the DOM model that you can read and write, while JSON // and /* comments */ are invisible to JavaScript programs. The…

I'm kinda sad that JSON has been struggling for like 15 years to get comments. Is there like some kind of gestapo that's saying no or something? All it takes is for the maintainers of probably 15 popular libraries to start handling comments. At the end of the day I'm sure the reason we don't have JSON comments is somewhere listed in this page: xkcd.com/927/

I believe Douglas Crockforf used to make the argument that JSON is not meant for human consumption and thus shouldn't be changed to better serve humans. I personally wish hjson (https://hjson.org) were to get more traction. I prefer it over both JSON and YAML.

Re: YAML: probably not so great after all (2017)

#292
post #208

Earlier quoted context omitted.

Trees are not graphs. You have to un-circularize your objects before stringifying.

Trees are always graphs. A tree is a an acyclic graph with a node designated as root.

You can have unrooted trees. See the second paragraph at https://en.wikipedia.org/wiki/Tree_(graph_theory)#Rooted_tre....

Re: YAML: probably not so great after all (2017)

#293

Earlier quoted context omitted.

I'm kinda sad that JSON has been struggling for like 15 years to get comments. Is there like some kind of gestapo that's saying no or something? All it takes is for the maintainers of probably 15 popular libraries to start handling comments. At the end of the day I'm sure the reason we don't have JSON comments is somewhere listed in this page: xkcd.com/927/

I believe Douglas Crockforf used to make the argument that JSON is not meant for human consumption and thus shouldn't be changed to better serve humans. I personally wish hjson ( https://hjson.org ) were to get more traction. I prefer it over both JSON and YAML.

It was Crockford. Directly from him:

> I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.

https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...

Re: YAML: probably not so great after all (2017)

#294

Earlier quoted context omitted.

I totally agree that in the ideal world, JSON should support comments. I yearn for them, and none of the in-band work-arounds or post-processing tools are acceptable substitutes. But to play the devil's advocate, how would JSON be able to support round-tripping comments like XML can, since are part of the DOM model that you can read and write, while JSON // and /* comments */ are invisible to JavaScript programs. The…

I'm kinda sad that JSON has been struggling for like 15 years to get comments. Is there like some kind of gestapo that's saying no or something? All it takes is for the maintainers of probably 15 popular libraries to start handling comments. At the end of the day I'm sure the reason we don't have JSON comments is somewhere listed in this page: xkcd.com/927/

I'm aware of at least three JSON libraries that at least can accept comments (Gson in lenient mode, Json.NET, and json-cpp are the ones I've used personally that do)-- it's hard to convince everyone that JSON needs comments, though, and comments are of limited utility if it's not guaranteed that they'll parse everywhere.

But you really only need comments in JSON if you're doing stuff like storing configuration in JSON, and JSON's too fiddly in general to be a great config file format (too easy to do something like forget a comma; no support for types beyond object, array, (floating point) number, and string). Something more like YAML without the wonky type inference would be better, IMO.

Re: YAML: probably not so great after all (2017)

#295

Earlier quoted context omitted.

Is there an implementation of strict yaml that you know of for Ruby?

If you are writing a new YAML implementation, then yeah, you want a simpler spec to follow. If on the other hand you are using a YAML library... I've had pretty good success using YAML compatibly across Python, Ruby, C# and Go projects. Do you have a particular issue in mind that the existing Ruby implementation doesn't address?

It's an implementation of YAML, not StrictYAML which has different semantics.

Re: YAML: probably not so great after all (2017)

#296
post #246

Earlier quoted context omitted.

You know what else is human readable, easy to parse if you're using PHP, and supports comments? PHP. I understand why some languages rely on common configuration file formats. I don't understand why the popular dynamic script-y languages don't more commonly use the natively-expressable associative/list data structures that they're famous for making convenient.

Interestingly, the Lua programming language actually evolved from configuration files: https://www.lua.org/history.html (and is still officially deemed useful for writing them)

I use Lua for configuration files for both personal and work related projects [1]. You get comments and the ability to construct strings piecemeal (DRY and all that). It's easy to sandbox the environment, and while you can't protect against everything (basically, a configuration script can go into an infinite loop), if someone unauthorized does have access to the script, you have bigger things to worry about.

[1] An example: https://github.com/spc476/mod_blog/blob/master/journal/blog....

Re: YAML: probably not so great after all (2017)

#297
post #75

JSON + comments + trailing commas + naked keys + multiline strings would be a great alternative. Maybe something like JSON5.

You'd really like HOCON[0] then. Just a bit too complicated to see wide adoption I'm afraid. 0 - https://github.com/lightbend/config/blob/master/HOCON.md

HOCON is awesome

Re: YAML: probably not so great after all (2017)

#298
I hear the arguments, and I’d say YAML is unbeatable

- when loaded safely

- when used by humans to edit obviously structured data of hashes and arrays

- and the humans are trained to double-quote potentially problematic entries.

This wins over xml or Json hands down.

Re: YAML: probably not so great after all (2017)

#299
post #216

Earlier quoted context omitted.

>I don't understand why the popular dynamic script-y languages don't more commonly use the natively-expressable associative/list data structures that they're famous for making convenient. You picked the wrong language... PHP comes with its own JSON parser. And INI and XML and even CSV. But, the reason is that, generally, you want config files to describe data or state only. Yes, you could just make your config native…

Any configuration will eventually become a programming language. See The Configuration Complexity Clock. https://mikehadlow.blogspot.com/2012/05/configuration-comple...

Just because it's common doesn't mean it should be encouraged by writing your config in native code to begin with.

INI is still simple, and JSON doesn't support logic, so the madness can be held at bay at least for a time.

XML and s-expressions are lost causes, though.

Re: YAML: probably not so great after all (2017)

#300
post #63

One thing to remember is that YAML is about 20 years old. It was created when XML was at peak popularity. JSON didn't exist (YAML is a parallel, contemporary effort). Even articulating the problems with XML's approach was an uphill battle. What you would replace it with is also hard. What use cases matter? What is the core model? A simple hierarchy? Typed nodes? A graph? What sort of syntax is needed for it to be usa…

Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below). * I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".

Try https://jsonnet.org/. Supports comments, plus a handful of additional useful features.
Post reply on HN