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

131–140 of 251 posts

Re: JSON with Commas and Comments

#131

Post by enw »

hn_throwaway_99 wrote: post #72
redisman wrote: post #61

Earlier quoted context omitted.

> The only reason JSON is as popular I mean I remember using XML for serialization back in the day and how it made we want to kill anyone who was involved in its creation. JSON won because it’s a great and simple standard and yes because it maps 1:1 to js. It was very popular with people who hated js when it came out too - just because of how much better it was than the other options

I think the move from XML to JSON mirrored a lot of the overall switch in the software industry at large from unnecessarily overly complicated "design-by-committee" specs to simple, get-shit-done practicality. (Heck, anyone remember the horror that was the original EJB spec, or god forbid, CORBA?) The rise in scripting languages like Python and JS on the backend is another example of this.

And I see this obsession in some people in the industry trying to prematurely optimize every drop in their code, but they don't understand the added complexity results in inefficiency (mostly lost improvement potential) in the long-term.

Re: JSON with Commas and Comments

#132

Post by ncallaway »

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.

> You want the date-only format? or the date+time format? If your data field conceptually represents a date (such as a date of birth, or the user's selection in the input of a date), use the ISO-8601 date.

If your data field represents a time (such as the selection of the time when a daily should recur each day), then you should use the ISO-8601 format with of a time.

If your data field represents a specific point in time (such as the time an action happened), then you should use the full representation of the date and time.

> you want the T separator or space?

When concatenating the date and time, the 'T' separator is used. Although, this is an implementation detail I've never had to touch myself, since every date library I've ever used has been able to format dates into an ISO format, and parse them from an ISO format without me having to consider the separator.

> Is time zone represented?

Again, this depends on what the data being represented fundamentally is. If it's a point in time that an event happened, yes. _Usually_ if you're representing a full date & time the answer is yes, you should represent the time-zone (I always serializing these dates in UTC and include the TZ).

The TZ should only be forgone if the data represents the abstract notion of a specific date and time, rather than a specific point in time.

To me (other than the "T" separator), these are all fundamental data questions, and not serialization questions. You need to know whether a field is a DATE, a TIME, a DATETIME and whether is a Zoned Date Time or a Local Date Time regardless of your serialization format.

ISO-8601 conveniently supports all these uses-cases and more.

Re: JSON with Commas and Comments

#133

Post by laurent92 »

crazygringo wrote: post #52

What's nice is that this can essentially be ignored by API's and browsers. Computer-generated data never needs to include trailing commas or comments. Really the principal use case here is JSON as human-edited configuration files. In which case I suppose it's nice to have a name like "JWCC", but really it's just two flags for JSON decoding libraries to add (or a single nice combined flag). So that really would be gre…

It doesn’t improve the dev experience if the compilers don’t produce it, and this is really about dev comfort. You need to be able to modify JSON programatically and keep the comments, if the output is pretty-printed.

Also, NaN numbers are an entire features, which they talk about above.

Re: JSON with Commas and Comments

#134

Post by BugsJustFindMe »

nooorofe wrote: post #128
BugsJustFindMe wrote: post #113

Earlier quoted context omitted.

> 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 schema exist exactly for that reason, hacks like adding type is just nonsense. If somebody need comments, types it - XML has all that. Also how hard is to write {"type": "datetime", "value": "2021-02-23 12:46:37.07"}?

> JSON schema exist exactly for that reason, hacks like adding type is just nonsense

Creating schemas for declaring types is literally a hack for adding type! I think its very bizarre to say "You dont need to do X because you can just do X."

> Also how hard is to write {"type": "datetime", "value": "2021-02-23 12:46:37.07"}

"datetime" isn't a universal format specification. 2021-01-10 could be October 1 or January 10. What time zone is this in? Local to the sender, UTC, local to the recipient, somewhere else? Is this a 24 hour clock or something that gets a modifier for the other half of the day? You're making some classic mistakes that people make when they don't think about the complexity of the problem domain of communicating information unambiguously.

Re: JSON with Commas and Comments

#135

Post by enw »

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

YAML is one of the worst formats I've ever encountered due to its mind-boggling complexity.

There's a ton of ways to represent booleans, a ton of ways to represent dates, a ton of ways to represent numbers of a ton of different bases, a ton of ways to represent strings of various line-endingness'. It really has caused a significant number of easily avoidable issues in my experience.

Re: JSON with Commas and Comments

#136

Post by Someone »

Swizec wrote: post #74
skeeter2020 wrote: post #73

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?

A json parser can discriminate between the integer 42 and the string “42”, but it cannot discriminate between the date 2021-02-23T08:10:19+0000 and the string “2021-02-23T08:10:19+0000” because in json, the date 2021-02-23T08:10:19+0000 will have to be encoded in a string.

That means your json parser either will accidentally parse some strings as dates, or will have to be told which strings are (or even might be) dates, introducing a partial schema, or it will have to leave it to the application to convert strings into dates. Workable? Somewhat, but not ideal, just as not supporting numbers, and leaving string-to-integer-conversion to the application (after all, JavaScript will happily convert strings to integers in eval) would be ‘not ideal’.

Also, are you going to accept 2021-02-23T08:10:19Z, too? Leaving out the seconds, minutes,…? for interoperability, you would have to specify that.

Re: JSON with Commas and Comments

#137

Post by resonantjacket5 »

recursive wrote: post #107
resonantjacket5 wrote: post #48

Earlier quoted context omitted.

Yes, but json by itself doesn't actually do anything. It'd always be used in context of javascript/python/ etc.. As I said you could interpret it as a tuple or I guess a frozen array for javascript? I don't think there is a native immmutable array in javascript. If it's a map I'm a bit more unsure how you'd check to find the object (quickly). You're basically getting into the how to store a struct/class as a map key.…

> I don't think there is a native immmutable array in javascript. I'm here to tell you that `Object.freeze()` works just fine on arrays.

Nice. Though I don't think that solves the rest of the issues I outlined sadly.

I guess you could have this json+ convert into some custom javascript class that allows arrays/objects as map keys rather than the normal javascript object that only accepts strings as map keys.

Re: JSON with Commas and Comments

#138

Post by stareatgoats »

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…

This is my preferred solution as well, nowadays.

Re: JSON with Commas and Comments

#139

Post by jonathanaird »

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.

Re: JSON with Commas and Comments

#140

Post by bawolff »

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

Post reply on HN