Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON with Commas and Comments

nigeltao.github.io

Post reply on HN
Print view View original

141–150 of 251 posts

Re: JSON with Commas and Comments

#141

Post by vidarh »

bawolff wrote: post #140
nly wrote: post #129

Let's stop pretending JSON isn't popular because it lets us be loosey-goosey with our specifications. Writing specifications is hard and time consuming, and getting people to follow them is almost impossible. JSON is something we can (almost) all agree on for dumping loosely specified, human readable representations of data structures. It lets users and client application developers be lazy and not have to learn a ne…

I think JSON demonstrates that most of the time you don't need it, and doing that sort of thing badly is worse than not doing it at all. E.g. XML has all that, and yet the average use of xml is much more fragile thsn the average use of json. Similarly asn.1 has all that, but does anyone actually like the fact the x509 certs use it? (To be clear, json would definitely not be appropriate for that case either).

There are both JSON [1] and XML [2] encoding rules specified for ASN.1... I have never seen it used in the wild, but realising it's a thing is horrifying enough.

[1] https://www.itu.int/rec/T-REC-X.697/en

[2] https://www.itu.int/rec/T-REC-X.693/en

Re: JSON with Commas and Comments

#142

Post by speedgoose »

jonathanaird wrote: post #139
nly wrote: post #129

Let's stop pretending JSON isn't popular because it lets us be loosey-goosey with our specifications. Writing specifications is hard and time consuming, and getting people to follow them is almost impossible. JSON is something we can (almost) all agree on for dumping loosely specified, human readable representations of data structures. It lets users and client application developers be lazy and not have to learn a ne…

I really want something that’s strongly typed but doesn’t require code generation like protobufs do. Yaml doesn’t do it for me. The closest I can get is putting the type guarantees in the database and using GraphQL.

I use JSON Schema to validate JSON documents.

https://json-schema.org/

Re: JSON with Commas and Comments

#143

Post by oneeyedpigeon »

geraldbauer wrote: post #125

FYI: I collect JSON variants with extension at the Awesome JSON - What's Next? page [1]. [1] https://github.com/json-next/awesome-json-next

I wonder if there's an equivalent for markdown variants. I wonder if there are more markdown variants or JSON variants.

Re: JSON with Commas and Comments

#144

Post by nly »

jonathanaird wrote: post #139
nly wrote: post #129

Let's stop pretending JSON isn't popular because it lets us be loosey-goosey with our specifications. Writing specifications is hard and time consuming, and getting people to follow them is almost impossible. JSON is something we can (almost) all agree on for dumping loosely specified, human readable representations of data structures. It lets users and client application developers be lazy and not have to learn a ne…

I really want something that’s strongly typed but doesn’t require code generation like protobufs do. Yaml doesn’t do it for me. The closest I can get is putting the type guarantees in the database and using GraphQL.

Strongly typed + no code generation is obviously doable in any dynamically typed language.

Apache Avro has support for parsing and utilizing schemas at runtime, even in C++.

For Apache Thrift you have things like thriftpy: https://thriftpy.readthedocs.io/en/latest/

I'm not aware of a type-safe mechanism for Flatbuffers or Protocol Buffers.

Re: JSON with Commas and Comments

#145

Post by matsemann »

ma2rten wrote: post #103
k_sze wrote: post #100

Earlier quoted context omitted.

> Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas. I think the most correct way to deal with this problem is to get IETF and ECMA to update the JSON standard first. Honestly, comma-after-final-element and comments…

I think that json is mostly a lightweight, human-readable data exchange format for machines to communicate. It's generally not meant to be written by humans.

But it's used for all kind of config files. And there I would like to comment why stuff is done the way it is.

Re: JSON with Commas and Comments

#146

Post by fiddlerwoaroof »

nly wrote: post #122
fiddlerwoaroof wrote: post #106

Earlier quoted context omitted.

Is the -0700 offset PDT or MST? ISO-8601 doesn’t solve a whole bunch of problems related to locale-aware date math.

Three character timezones like "PDT" also aren't good enough because they make it too easy to encode timestamps that don't make sense, like a British Summer Time (BST) time in December. To be honest I think you're better off just not encoding the timezone in your main timestamp string at all and instead adding the full IANA timezone name (e.g. "Europe/London") in to a separate field. In sensible formats all the dates…

Yeah, I'm just using the three character timezone as a handy shortcut: the point is an ISO-8601 timestring isn't unambiguous in all contexts.

Re: JSON with Commas and Comments

#147

Post by nly »

vidarh wrote: post #141
bawolff wrote: post #140

Earlier quoted context omitted.

I think JSON demonstrates that most of the time you don't need it, and doing that sort of thing badly is worse than not doing it at all. E.g. XML has all that, and yet the average use of xml is much more fragile thsn the average use of json. Similarly asn.1 has all that, but does anyone actually like the fact the x509 certs use it? (To be clear, json would definitely not be appropriate for that case either).

There are both JSON [1] and XML [2] encoding rules specified for ASN.1... I have never seen it used in the wild, but realising it's a thing is horrifying enough. [1] https://www.itu.int/rec/T-REC-X.697/en [2] https://www.itu.int/rec/T-REC-X.693/en

I've used BER encoded ASN.1 at work quite a bit, and the reason you won't see it much are pretty much:

- HORRIBLE schema format.

- Very few FOSS libraries, most of which are terrible. I used Lev Walkins asn1c[0], which I patched slightly and coupled with some semi-generic code that walks the generated data structures to emit JSON (for debugging purposes).

[0] https://github.com/vlm/asn1c

Re: JSON with Commas and Comments

#148

Post by kergonath »

_ZeD_ wrote: post #94
glennpratt wrote: post #89

Just use YAML. JSON is valid YAML.

Problem is... YAML sucks, as human readable format

YAML is fine as a user. It can be just JSON without some of its visual clutter if you like brackets, or much more concise if you prefer.

All the complexity related to anchors and such is unfortunate, but that’s a problem for parser writers.

Re: JSON with Commas and Comments

#149

Post by _0w8t »

For comments in plain JSON a common approach is to use keys like "comments" or "description" in object literals.

As for trailing comma the only real issue in practice is noisy unified diff output. But for JSON word diff or similar works better in any case when the trailing comma is not an issue.

Re: JSON with Commas and Comments

#150

Post by coldtea »

eesmith wrote: post #116
coldtea wrote: post #58

Earlier quoted context omitted.

> That wasn't the original goal of JSON. That's neither here, nor there. The narrow vision many/most tools were created with is laughable compared to the actual creative uses people put them into. Heck, the internet wasn't created for collaborating, socializing, shopping, reading, listening to music, etc., anyway, it was created to have a war-proof network for army use, yet here we are...

ARPANET, the direct predecessor for the internet, was created for collaborating, including socializing and reading. It was NOT created to "have a war-proof network for army use". The latter is a pernicious falsehood. Quoting https://en.wikipedia.org/wiki/ARPANET : > It was from the RAND study that the false rumor started, claiming that the ARPANET was somehow related to building a network resistant to nuclear war. Th…

From the very page you link to:

Nonetheless, according to Stephen J. Lukasik, who as Deputy Director and Director of DARPA (1967–1974) was "the person who signed most of the checks for Arpanet's development:

"The goal was to exploit new computer technologies to meet the needs of military command and control against nuclear threats, achieve survivable control of US nuclear forces, and improve military tactical and management decision making."

Post reply on HN