Hacker News Reader

Comment by web007 | Hacker News Reader

I'm surprised this got voted up considering how dismissive (and, frankly, mean) HN was to "JSON5" a few years back https://news.ycombinator.com/item?id=4031699

Trailing commas have been fine everywhere in JS since IE7 - it's about time all interpreters have this as an option, and preferably on by default.

View on HN

Trailing commas are commonly allowed in the subset of JS that is JSON, but I believe most JSON parsing libraries disallow them.

You can always parse using an eval. I guess it should work.

/me ducks.

Sigh.

Don't duck too much. This kind of config implementation is actually pretty common in some other languages. Clojure, for example. Most configuration files for Clojure programs are written in Clojure, and defended as such.

I also see it frequently done in Python and Ruby, given how simple they make it to dynamically import random files as modules. I've even watched a colleague rant about how they couldn't figure out how to do exactly this in Go.

Anyone looking for a “better JSON” night was well just move to YAML. Someone managed to make JSON5 the config format for something here and we wasted way too long before switching that over to YAML. Now we have a bunch of JSON5 with comments we’ve gotta manually transcribe.

Every YAML parser I've ever used has been literal magnitudes slower than the slowest JSON parser. It's way too flexible a format.

> YAML may seem ‘simple’ and ‘obvious’ at a glance, but it’s actually not. The YAML spec is 23,449 words; for comparison, TOML is 838 words, JSON is 1,969 words, and XML is 20,603 words.

https://arp242.net/weblog/yaml_probably_not_so_great_after_a...

If data is so big that parsing is a bottleneck, that seems like the wrong case for YAML. It's good for hand-edited and human-readable config files, and it's fast enough for that.

Hand-edited and human-readable? With significant whitespace and tab-space difference?

Human readability is exactly the point of significant whitespace. And I'm not sure how significant whitespace could even work without distinguishing between tabs and spaces, as a tab could represent any number of spaces.

You cannot indent yaml with spaces instead of tabs. This has been a source of confusion for years for many bukkit end-users.

Toml is far superior for hand editing. This is why yaml is terrible (aside from significant white space):

    foo: 80:80
    bar: 22:22
    baz: 22.22

What's the value of foo? It's the string "80:80". What's the value of baz? The float 22.22 What's the value of bar? The integer 1342.

I rest my case about both readability and writability.

> bar: 22:22

I know zero toml (don't even know what toml stands for) but I'm pretty sure you meant the value of bar is the string 22:22 based on foo.

I think he's attempting to point out a shortcoming of yaml; I can reproduce it myself in Python.

That said, I've never run up against this myself - in the face of potential ambiguity I attempt to be explicit, and surround it in quotes to be explicit string.

TOML itself is going through its own growth pains brought on by a rather sizable spec. For example:

    >>> pytoml.loads("foo = 20:20:20")
    [...]
    pytoml.core.TomlError: <string>(1, 9): msg

I agree that's a downside, but it almost never comes up in practice, and it's solved by syntax highlighting when it does. I'm always in a code editor when editing YAML, it's not something that goes down the wire and needs to be debugged without syntax colours. For config files it's fine. Maybe TOML is even better, I haven't used it. I'm just saying these problems raised about YAML have never really affected me and I use it all the time. For config only. JSON for data exchange.

If it's something you do thousand of times a second, like say a php app parsing a config it makes a HUGE difference. A number of PHP framework that use YAML config files actually cache the results in memcache because a network request is faster than parsing YAML from local disk.

If it's something you do thousands of times a second, then opening, reading, and parsing a config file is absolutely something you should be caching, no matter the implementation.

It's got a lot of bad features which should not really be used. The core is good though.

The problem with talking about 'cores', is I still have to parse and handle the entire language if I want to claim to support YAML.

I've used JSON is some constrained places, I can't imagine writing my own YAML parser, or hacking an existing one into a constrained place (no memory allocation for example).

First, JSON is not just used for config, and I've yet to find the an API to parse YAML in the browser natively.

Secondly, JSON is here and you have to deal with it everyday, so smoothing the work wouldn't hurt.

Finally, if you have to pick a format, take TOML. Less error prone than YAML, faster, and injecting executable code and shooting your in the foot is not part of the standard. The fact that a lot of ini files are valid toml is a nice bonus.

I cannot follow TOML at all. YAML is nice and obvious in the limited basically json subset I use whereas nested maps in TOML are a nightmare.

Reply on news.ycombinator.com