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

151–160 of 251 posts

Re: JSON with Commas and Comments

#151

Post by willtim »

aaron-santos wrote: post #2

> Yes, Doug Crockford deliberately removed comments from JSON but people keep putting them back in. If we’re going to have comment-enriched JSON (e.g. for human-editable configuration files), we might as well have a standard one. The text "deliberately removed comments from JSON" links to https://web.archive.org/web/20150105080225if_/https://plus.g... where Doug not only explains the reason, but also a solution which…

> A new format is a really weird way to go about fixing a problem that already has a solution.

Stripping comments before handing off to a JSON parser is not a full solution. For example, if the file has to be augmented with additional data and written out again, the comments would be lost.

Re: JSON with Commas and Comments

#152

Post by jobigoud »

SPBS wrote: post #124

I've been finding plain JavaScript as a very nice alternative to the many config file formats out there. It already has the trailing commas + comments bells and whistles, plus the ability to do computation to generate repetitive elements. Of course there's always the danger of the user creating a monstrosity of a 'config file' but if they're the ones using the software that consumes the config file, that's on them to…

Turing complete config files makes me a bit nervous.

Re: JSON with Commas and Comments

#153

Post by arcatek »

sneak wrote: post #119
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…

Comments were intentionally excluded from JSON, lest they be used to instruct the parser and cause fragmentation of the ecosystem.

I know it's the official reason, but it's also a really bad one - nothing prevents current JSON parsers to add some weird syntactic rules inside plain strings (similar to "use strict" in JS), but you don't see that happen. It's always been a completely hypothetical issue.

The only real reason why comments would be problematic is that they are a pain to preserve in a consistent way when editing a file, and thus would require extra work in parsers / serializers. Still, it would be worth the cost imo.

Re: JSON with Commas and Comments

#154

Post by tracker1 »

didibus wrote: post #43
hn_throwaway_99 wrote: post #31

Earlier quoted context omitted.

I can't believe that anyone who has ever wanted to comment a package.json file could think Crockford's argument is anything but nonsense. The problem is these files are both edited by humans, and by a plethora of tools. Without a standard comment format, it's been a nightmare trying to comment package.json file in a way that doesn't break something in the NPM/Node ecosystem.

Using JSON for configuration could be the mistake? That wasn't the original goal of JSON.

I think TOML and YAML are both better for configuration files.

Re: JSON with Commas and Comments

#155

Post by nly »

speedgoose wrote: post #142
jonathanaird wrote: post #139

Earlier quoted context omitted.

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/

Imho, statically typed languages are the ones that benefit most from schema. The current schema version is 12 but the implementations for Go, Rust, C++ and Java are all listed as draft 7. None of them support codegen either, just validation, so not exactly compelling.

Re: JSON with Commas and Comments

#156

Post by kstenerud »

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 made https://concise-encoding.org/ to deal with this:

- strongly typed

- ad-hoc or schema (your choice)

- no code generation step

- edit in text, send in binary

Re: JSON with Commas and Comments

#157

Post by oblio »

BiteCode_dev wrote: post #118
k_sze wrote: post #104

Earlier quoted context omitted.

There are already better formats if we just want machines to communicate though; e.g. protobuf, msgpack. The whole reason JSON is text-based is to make it human-readable while also enabling data exchange, but the lack of comments works against that goal.

Not in the browser or in many stalin.

> many stalin.

Wasn't there just one Stalin, though?

Re: JSON with Commas and Comments

#158

Post by secondcoming »

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…

Json does have schemas

Re: JSON with Commas and Comments

#159

Post by lloeki »

nly wrote: post #155
speedgoose wrote: post #142

Earlier quoted context omitted.

I use JSON Schema to validate JSON documents. https://json-schema.org/

Imho, statically typed languages are the ones that benefit most from schema. The current schema version is 12 but the implementations for Go, Rust, C++ and Java are all listed as draft 7. None of them support codegen either, just validation, so not exactly compelling.

I benefit greatly from schema validation in Ruby, ensuring that ingress-processing code does not receive e.g a String or Hash instead of an Array which would have things blow up way after the ingress edge when a call to an Array method fails, or worse, produce silently broken behaviour that may or may not blow up even farther down the road because both String and Hash respond to e.g #[](Integer).

Re: JSON with Commas and Comments

#160

Post by vidarh »

nly wrote: post #147
vidarh wrote: post #141

Earlier quoted context omitted.

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

I've implemented (a subset of) ASN.1 for an SNMP server I wrote for an embedded monitoring system, so I know the pain, but it was one thing to implement it for a compact binary format. Inflicting it on a text-based format just seems like it'd multiply the pain...
Post reply on HN