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

191–200 of 251 posts

Re: JSON with Commas and Comments

#191

Post by argvargc »

People use JSON For configuration files? What a PITA. Use a tool suited to the job, eg, TOML.

https://en.m.wikipedia.org/wiki/TOML

Not that there's anything wrong with adding comments and commas to JSON. Call it JSONv2, keep the .json extension and let people bump around upgrading for a bit. It's hardly much of a change but has significant benefits, even outside the config file use. For instance it can sometimes be useful to annotate raw data, and it'd be nice to have that built in. Certainly the commas is a no-brainer.

Re: JSON with Commas and Comments

#192

Post by ritchiea »

knome wrote: post #105
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 never understood why they weren't part of the original spec https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... >Trailing commas in objects were only introduced in ECMAScript 5. As JSON is based on JavaScript's syntax prior to ES5, trailing commas are not allowed in JSON. json was largely `eval`d when it first hit the scene. It was easy to parse because you just received it and `eval`d it directly to p…

Interesting note: Douglas Crockford's version of JSON's origin story is great. At Yahoo Crockford wanted to return data from an API as a Javascript object because it skipped a translation step and avoided messy XML. And his bosses originally objected because there was no JSON spec. So Crockford bought a website, quickly wrote up a JSON spec and published the spec to his new official looking JSON.org site. With an official spec in place and documented on the web, there was no longer cause for his bosses to object to APIs returning JSON :)

Re: JSON with Commas and Comments

#193

Post by rualca »

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

I believe it's hard to explain JSON's popularity and wide adoption without talking about javascript. With javascript, JSON was right from the start an ‘eval’ away from being parsed. The barrier to entry to adopt it simply was never there. Once you start to expose JSON APIs to clients, other servers also start to need to consume data from those servers. Rinse and repeat until you reach mass adoption.

Re: JSON with Commas and Comments

#195

Post by q3k »

flohofwoe wrote: post #184
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…

> Pretty much every language on the planet has JSON parser libraries.

Yes, but they all implement the JSON RFC slightly differently, or implement it in a totally non-compliant way.

Re: JSON with Commas and Comments

#196

Post by indymike »

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…

Suppose simple > complex wins sometimes. JSON was a serialization format. XML was a markup language being used for serialization... and created a lot of extra work and bugs for developers. Markup languages can be incredibly useful (evidence: the web, SVG), but often bring immense complexity to simple problems.

Re: JSON with Commas and Comments

#198

Post by em500 »

sep_field wrote: post #102
ncallaway wrote: post #83

Earlier quoted context omitted.

I'd recommend always representing dates or datetimes as a string in ISO-8601 format.

Which ISO-8601 format though? There are a variety to choose from. You want the date-only format? or the date+time format? you want the T separator or space? Is time zone represented? All these are allowed according to the ISO standard.

Sure, but all of those variations can be parsed unambigously as long as it's communicated to be an ISO-8601 datetime.

Re: JSON with Commas and Comments

#199

Post by XelNika »

crubier wrote: post #98
_ZeD_ wrote: post #94

Earlier quoted context omitted.

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

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

As a human-readable configuration language, YAML probably beats JSON and XML, but the implicit typing rules in the spec make it horrible to work with. I've written a lot of YAML for Ansible and it has some awful footguns.

Re: JSON with Commas and Comments

#200

Post by nmg »

ash wrote: post #167
treve wrote: post #60

The page addresses that there are other alternatives/supersets. I think the most common one that has decent adoption is JSON5. I would like to see why the author chose to do yet another format, vs adopt JSON5.

I find that JSON5 does too much.

What are your specific dislikes?
Post reply on HN