121–130 of 251 posts
I actually think the lack of comment support in JSON has resulted in better naming and better documentation by those who create JSON to be consumed by others. I don’t want comment support in JSON at this point personally.
Earlier quoted context omitted.
I've never had a problem with dates by always serializing them as ISO-8601. It absolutely has every benefit you cite. It's the only ISO spec I know the name of without having to look it up.
Is the -0700 offset PDT or MST? ISO-8601 doesn’t solve a whole bunch of problems related to locale-aware date math.
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 within a single JSON object or object will have the same timezone anyway, and to save bytes you can simply say in your spec "If absent, assume UTC".
Could we solve dates first, then worry about comments and commas?
ISO-8601 not good enough for you? It’s a standard, human readable, has every datetime detail, every language that supports JSON can read it. What’s missing?
Another problem with ISO is the specs aren't freely available, so people will generally guess or refer to old versions, drafts, or RFCs (like RFC 3339)
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
Earlier quoted context omitted.
Or just do RSON? https://github.com/rson-rs/rson I honestly don't want to bash JS, but typing is not it's strength. (Not affiliated)
I think that's the opposite of what GP is advocating; they're arguing that a better approach than defining entire new formats, we should just augment existing JSON implementations. I'd guess that the rationale is that it would be a tougher uphill battle to get people to switch to an entirely new format, but adding new features to implementations they're already using wouldn't require making anyone switch.
Earlier quoted context omitted.
> If Crockford's argument was "I got rid of comments because people were using them for preprocessor directives", then he just made the problem a million times worse because now there are a million different, incompatible "preprocessor directives" No, because his goal was to make JSON a highly-compatible interchange format, which it is! There are roughly zero incompatible preprocessor directives, and roughly zero pro…
> Seriously, when have you received JSON that you couldn’t immediately parse with your standard JSON parser of preference? Every single time for any non-mediocre definition of parsing. JSON has no way to transmit the meaning of values, no datetimes, no units, no sets, nor any other semantic attribute. That means your "parsed" result is always useless and wrong on its own, literally a lesser-dimensional projection of…
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 new library for our preferred data format. The lack of schemas or validation means we can often get away with wishy-washy, hand-written, plain English specifications, or specifications "by example". It's convenient.
For anything intended to be robust, for serious data interchange, use something else. Anything with support for machine-readable schemas, validation, and robust encoding rules. Binary is preferable but a JSON serialization is still a must-have escape hatch.
And here's a shocking idea... provide your clients with an SDK. It's pretty easy to build one around a multi-language data serialization framework and maintaining an SDK is still easier than maintaining a spec that your clients will probably implement incorrectly.
Earlier quoted context omitted.
Given the number of times people have invented and re-invented JSON + comments, I think it's clear there is a demand for JSON + comments, and that Crockford's view that you can solve everything by asking people to manually strip the comments out before parsing the JSON isn't viable.
Petabytes of JSON formatted data flowing across the internet every second of every day disagree with your assessment.
(Also, as gets pointed out every time this topic pops up on HN, including multiple times on the submission already, the main demand isn't people wanting to add comments to the JS flowing across the wire, but to config files sitting on disk. Responding to people saying "feature X would help use case Y" by noting how many people are using it for use case Z even without feature X is logically incoherent.)