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

181–190 of 251 posts

Re: JSON with Commas and Comments

#181

Post by HelloNurse »

arcatek wrote: post #153
sneak wrote: post #119

Earlier quoted context omitted.

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…

In most applications reading and writing JSON are completely separate operations and roundtripping comments makes no sense.

Actual JSON-reading applications must ignore comments because they aren't allowed to care about them. On the other hand anything useful can be placed in a proper field, a comment would be a hack to pass information to human readers but not to JSON consumers (saving some time and memory). Such a technique could only be considered if people are supposed to read the JSON files and some information is useful for them but not for the reading application: a niche within a niche.

Preserving comments would actually be a complicated special purpose feature, reserved for something like structured text editors that can perform nonstandard parsing with comments included in their special object model (of the large Javascript subset/superset/variant they choose to support and roundtrip, not of JSON).

Re: JSON with Commas and Comments

#182

Post by tikkabhuna »

johnisgood wrote: post #126
crubier wrote: post #98

Earlier quoted context omitted.

No it doesn’t. I know the HN-crowd feeling about this, but no, YML doesn’t suck as a human configuration language. TOML or XML properly suck. YML is actually a superset of JSON with comments and less brackets if you want. It’s widespread and supported and fulfill the need of OP, so no need to add yet another format. Or use JSON5. But please not yet another standard

Why do you think TOML sucks for configuration files? I use it everywhere and it has been a joy so far. Granted, I only used it with Go, but it has been a great experience, and the configuration files are nice. For configuration files I would rather use TOML than JSON. For other stuff? I would probably go with ASN.1!

How complex is your configuration? I've used TOML for Traefik config[1] and I've found there's so much repetition.

The single/double square bracket thing is also non-obvious at first.

[1] https://doc.traefik.io/traefik/routing/routers/

Re: JSON with Commas and Comments

#183

Post by wruza »

redisman wrote: post #67
uDontKnowMe wrote: post #12

IMO it would also be really nice to have non-string keys in objects, like: { [1, 2]: "a", [3, 4]: "b" }

Why?

One of the uses is mapping values to objects instead of strings, so you don’t have to use ids:

  ob = {...}
  somemap[ob] = value
  // vs
  somemap[ob.id] = value
In languages which allow weak keys in such maps, a garbage collector may even reclaim whole key-value pairs once ob falls out of existence. But to my opinion, in json it is barely useful for a number of reasons. It is more programming technique than data transfer format, and these features (and reference loops) should be encoded at a higher level than json.

Re: JSON with Commas and Comments

#184

Post by flohofwoe »

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…

What programming languages and platforms will your SDK be compatible with, will you also be around to port the SDK to new platforms in twenty or thirty years? Those are good reasons to agree on a standardized data format instead of a specific implementation. Pretty much every language on the planet has JSON parser libraries, and if not, it's fairly trivial to write your own (or convert the JSON data to something else).

Re: JSON with Commas and Comments

#185

Post by bshimmin »

zeroimpl wrote: post #10

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. Most parsers support various flags already to configure things, so there could just be an ALLOW_COMMENTS flag and ALLOW_TRAILING_COMMAS flag. As a case in point, th…

Wouldn't you just end up with (for example) "Python-flavoured JSON", just like we have "GitHub-flavoured Markdown"?

On the other hand, there is an RFC for JSON where there isn't for Markdown, so it ought to be possible to make use of the usual standards process to formalise a successor to the original JSON which might include some of the very common additions some people always want (trailing commas, comments, proper dates) - that this hasn't happened over the last 15 years suggests really that the problem is actually due to lack of agreement.

Re: JSON with Commas and Comments

#186

Post by PixyMisa »

kstenerud wrote: post #156
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 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

That looks pretty good, actually.

Re: JSON with Commas and Comments

#189

Post by nly »

lloeki wrote: post #159
nly wrote: post #155

Earlier quoted context omitted.

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).

Yeah but Ruby is a dynamically typed language. There's not much benefit to codegen since nothing is checked at compile time anyway.

Re: JSON with Commas and Comments

#190

Post by biztos »

cout wrote: post #176
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 the reason JSON caught on outside of the javascript community is because it provided a succinct way to represent tree structures of common types (numbers, strings, dictionaries, and lists), using a syntax familiar to anyone who has used C, Perl, Python, Ruby, or Java. S-expressions might have caught on for this purpose, but they lacked a killer app (jquery, and later rails). Like JSON, they are easy to parse…

I think the reason JSON caught on outside the Javascript community is because it caught on so massively inside the Javascript community, at a time when there was a lot more crossover between people working on the javascript layer of web apps and people working on the server side (back then, almost always in a different language).

I was doing mostly Perl and Javascript when it caught on, and to this day I have very mixed feelings: it's wasteful of space but still doesn't allow comments; its type system is basically a technical-debt generator; and for all that people still get it wrong pretty often. On the other hand, it's more or less human readable for simple data structures and it's more or less everywhere.

My hunch is that for a new format to take off it wouldn't so much need to not fall between YAML and JSON: it would need to be the default format of something with such super exponential growth that even us oldies would have to use it.

Post reply on HN