Hacker News Reader

Comment by Waterluvian | Hacker News Reader

My opinion only: I love JSON because it lacks so many foot guns of yaml. If you’re doing lots of clever stuff with yaml you probably want a scripting language instead. Django using Python for configs made me fall in love with this. Spending years with the unmitigated disaster that is ROS xml launchfiles and rosparams makes me love it even more.

Yaml and toml are fine if you keep it simple. JSON direly needs comments support (but of course wasn’t designed to be used as a human config file format so that’s kind of on us). And not just “Jsonc that sometimes might work in places.”

Beyond that, I think we generally have all the things we need and I don’t personally think we need yet another yaml. =)

View on HN

These aren't foot-guns per se, but I can think of another handful of grievances I have with JSON:

* JSON streaming is a bit of a mess. You can either do JSONL, or keep the entire document in memory at once. I usually end up going with JSONL.

* JSON itself doesn't permit trailing commas. I can measure the amount of time that I've wasted re-opening JSON files after accidentally adding a comma in days, not hours.

* JSON has weakly specified numbers. The specification itself defines the number type symbolically, as (essentially) `[0-9]+`. It's consequently possible (and common) for different parsers to behave differently on large numbers. YAML also, unfortunately, has this problem.

* Similarly: JSON doesn't clearly specify how parsers should behave in the presence of duplicate keys. More opportunity for confusion and bugs.

2, 3 and 4 can be caught early with JSON schema.

Not really, json schema validation is applied after json parsing on already parsed json.

the funny thing is that json doesn't even need commas, they essentially act as whitespace, any amount or no amount would make no difference in the meaning of the document.

Arrays with hole are a JS-only feature

> json doesn't even need commas

JSON is defined by the spec. The people who wrote the spec think otherwise[0].

[0]: https://www.json.org/json-en.html

> Arrays with hole are a JS-only feature.

There are other langauges that allow arrays with missing elements.

JSON requires commas, but does not need them, semantically they are treated like whitespace

The document > {1:2 3:[4 5]}

can only be "commafied" to > {1:2, 3:[4, 5]}

> There are other langauges that allow arrays with missing elements.

But javascript is the only one that gave JSON the JS in its name

Running prettier (https://prettier.io) on each save will fix trailing commas for you. If you accidentally have one, it will just sneakily remove it and turn your document into one that is valid.

You can parse JSON in a streaming fashion with many libraries. You just don't know at the beginning if it is going to be valid or not.

And the flip side of that with YAML is you can stream it, but you don't know once you've gotten to the end if it was the whole document without some user defined checksum mechanism.

Ran into a great bug with the INI format which has the same issue. The application would read the config file on modification but if you just wrote over the file it would sometimes read the config before the file was fully written. Have to use a temp file and move it rather than just edit it.

It's possible to have document start and end markers in yaml:

    ---
    foo: 1
    ...

Your application can mandate usage of these. But yeah, not ideal.

> Your application can mandate usage of these

I believe that's only true if one were to load YAML via the "SAX"-style per-event stream, and not the "object materialization" that normal apps use (aka `yaml.load_all` or JAX-B objects) since in those more data-object centric views, where would one put the processing events for those markers?

I also originally expected `yaml.parse(...)` to eat them as it does for comments and extraneous whitespace, but no, it does in fact return dedicated stream events for them, so TIL

How someone could have decided on a subset of javascript and not include comments is beyond me.

It may have been a good or bad decision. But comments were intentionally left out of JSON to avoid obvious ways to sneak in parsing directives and thus incompatibilities between different JSON-parsers.

Yet incompatibilities persist from day 1: big integers, duplicate keys, keys order.

On the other hand, XML allows comments, yet I've never seen XML parsers incompatibilities.

Not exactly an incompatibility, but my mind jumped to issues like this: https://github.com/swisskyrepo/PayloadsAllTheThings/blob/mas...

    <NameID>user@user.com<!--XMLCOMMENT-->.evil.com</NameID>

Some parsers will take just the first text element ("user@user.com"), and others will concatenate the text elements ("user@user.com.evil.com").

> Some parsers will take just the first text element

Those are not in compliance with the relevant spec. We need to treat them as damage and confront them on the technical and social level.

If I had a penny every time someone tried to parse xml using a regex, if that classifies as a parser. Those are 100% incompatible with everything else.

Easiest way to demonstrate how wrong that is, is to throw in a comment in the example document ;)

> Django using Python for configs made me fall in love with this.

I also started advocating in-language configuration files (Python for Python, but also Lua for Lua, etc) a number of years ago because it lets you do really useful things (like functionally generating values, importing shared subsets of data, storing executable references, and ensuring that two keys return the same values without manual copy/paste) all without needing to spec and use Yet Another Thing™ that does only a fraction of what the programming language you're already using already does.

That also implies that you can't just test a foreign config file without first reading and understanding what it does, as just using one would imply arbitrary code execution.

This is a place where Tcl excels. You can easily create restricted sub-interpreters that can't do anything dangerous. If you need more power for trusted scripts you just reenable selected commands.

Same thing with with Lua!

That is how our Tcl based application server was, the configuration files were a Tcl DSL.

Using the programming language to do the comments works only when using some scripting language.

Things that get compiled can't really use it without recompilation.

But you can embed Lua or Python using its C interface.

> My opinion only: I love JSON because it lacks so many foot guns of yaml.

While true, parsing it is still a minefield because it's very underspecified: http://seriot.ch/projects/parsing_json.html

JSON5 is the way to go. It supports comments and trailing commas. Unfortunately it's going to be difficult to supplant legacy JSON, which is so pervasive.

Except parsing JSON5 in browser is super slow. Native JSON.Parse doesn't support it, non-native parsnips are slow, and the only fast way to parse it is `eval()`.

Does the browser need JSON objects with comments?

The desire to use a single interchange format for all data is the problem. There are plenty of reasons to support comments and minor syntax issues that JSON itself dislikes for human consumable and interactive JSON. I'd think software JSON could be just that.

This shouldn't really matter for the JSON5 use case - config files - which are usually small enough.

For machine-to-machine generated payloads JSON is good enough.

I work with ros extensively and have not heard of using django for this use case. do you know of any open source projects that do this?

Sorry. Two separate contexts. I use both in the big picture but the Django world doesn’t directly interact with ROS. there’s an HTTP api for that.

Reply on news.ycombinator.com