JSON is usually the least bad option for machine-readable output formats | Hacker News Reader

JSON is usually the least bad option for machine-readable output formats

utcc.utoronto.ca

20 pointsluu14 comments

I just wish everybody adopted JSON7, all the advantages of JSON6 + a few more human ones.

Sure, but I just wish everybody adopted JSON5, all the advantages of JSON + a few more human ones.

The beauty of JSON is it's rigid structure, especially from a parser standpoint. The number of "may"s in the JSON5 spec sounds like hell to implement.

It's not too much work, although things like unquoted tokens do introduce some ambiguity (a technical term for when two productions have overlapping start symbols) in the grammar. This is usually an academic concern though, as ambiguity can be resolved through backtracking, and as long as you don't require too much of it, it's fine.

I've implemented a hand-written recursive descent parser for something that is very similar to JSON5, and it wasn't difficult overall.

But all of my services speak JSON, so if I can do a tiny bit more work to speak the same language, that's an advantage that JSON5 loses over JSON. I don't think JSON5 is enough more human-friendly to make up for that rather large disadvantage.

I just wish everybody adopted JSON6, all the advantages of JSON5 + a few more human ones.

I wish people adopted a JS name convention for putting Semantic Types into Variable Names. It wouldn't require a JSON spec change.

Like: {"greeting$string":"hi :D"}

JSON5 is for inputs, this article is about outputs.

I have to disagree, to me, the best is flat fixed length text files with csv files being a close second.

I hope you are a troll

At least they're not advocating for xml.

What’s wrong with xml? Unlike JSON, its standard supports references.

The sheer volume of human effort spent on xml means that there are some pretty great libraries out there for working with it.

Just terribly unfit for human consumption.

Reply on news.ycombinator.com