News for hackers. Stuff that matters.
Re:JSON with Commas and Comments by hn_throwaway_99 on Tuesday February 23, 2021 @12:22AM (#26234075)
I don't understand why you keep making the same circular arguments. If the lowest-level standard for JSON-encoded data also included comments and trailing commas, than I have no doubt that every combination of JSON-encoded data and JSON parser would be able to parse that. Instead, it wasn't put in the lowest level spec, so instead what you have are lots of individual parsers with non-compatible custom flags. 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" that are just implemented as basically command line args now if a user wants to have a very basic feature, which is comments.
Re:JSON with Commas and Comments by tshaddox on Tuesday February 23, 2021 @01:01AM (#26234258)
> 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 problems using JSON to exchange data between parties. Seriously, when have you received JSON that you couldn’t immediately parse with your standard JSON parser of preference? The fact that some people might devise their own tools to store incompatible JSON on their end with things like comments, and strip those things out when transmitting them in order to make them compatible JSON, does not qualify as an incompatible preprocessor directive. On the contrary, thats precisely the intent of the choice to not have comments in JSON.

Re:JSON with Commas and Comments by BugsJustFindMe on Tuesday February 23, 2021 @01:46AM (#26234488)
> 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 the original information, until you interpret it again in an entirely ad-hoc custom manner. Wouldn't it be nice if you could store instructions inline for how to do that.

Re:JSON with Commas and Comments by nooorofe on Tuesday February 23, 2021 @02:47AM (#26234797)
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"}?
Re:JSON with Commas and Comments by BugsJustFindMe on Tuesday February 23, 2021 @03:12AM (#26234930)
> 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 by nooorofe on Wednesday February 24, 2021 @09:02AM (#26249894)
> Creating schemas for declaring types is literally a hack for adding type!

It is a "communication protocol" - base of any messaging system. Message has header with protocol name and version: HTTP, TCP, DB connection, SOAP, any message queue - everything working that way.

> "datetime" isn't a universal format specification. than use another (see the comment above)

self-contained message is anti-pattern