[eclectic29]

One man’s extremely horrible mistake and look how the whole industry has been suffering for decades - countless articles debating the existence or absence of comments, new formats, new parsers, new ways of adding comments, post-processing, etc. What a pity!

[m463]

There's something to be said for the hard limitations of json that made it successful.

Because of that it didn't become XML or YAML or markdown or protobufs or *RPC or microsoft config file format or all the rest. All those formats have "reasons", but they are harder to understand, harder to parse or not as portable or on and on...

(that said, I wouldn't mind comments. JUST comments).

[whizzter]

Most reasonable parsers has an allow-comments flag, and even in JS you could it in a simple regexp replace all with:

const obj = JSON.parse(jsonText.replaceAll(/("(?:\\"|\\.|[^"])"|[^\/])|\/\/.|(\/)/g,"$1$2"));

The above should be multiline JSON safe and give you single-line comments to end-of-line, it matches first strings (and checks for escaped double-quotes and escapes to get them correctly) or all other characters except // sequences (outside of strings) and passes that straight through via group 1(anything outside of string not starting with /) or 2(single / even if it's outside of JSON spec), if a // sequence is found it's not passed through and disappears.

Yes, regexps can be abused. This one should be fine though but only use it for config files you control :), use as CC0 and keep an keen eye if translating to another language since escapes will differ if the regexp goes into a string instead of a regexp literal like in JS.

[pavlov]

It’s better than having to deal with the ad hoc out-of-band data formats that people would inevitably have stuffed into comments if given the opportunity.

Remember how JavaScript used to reside inside a HTML comment?

[lolinder]

> It’s better than having to deal with the ad hoc out-of-band data formats that people would inevitably have stuffed into comments if given the opportunity.

As has been pointed out multiple times in the thread so far, a random string that is ignored by the receiver is semantically equivalent to a comment, and people totally stuff random crap into strings to extend the data format in sometimes-horrifying ways. Banning comments doesn't stop us from abusing strings, it just means we don't have a good way to indicate that a part of the file should be ignored by the parser because it's not actually data.

[hombre_fatal]

But the problem isn't with abusing strings, but abusing something that isn't data.

Abusing the string is the correct place to put poorly planned data because it's just data and it has a stable position in the data (and syntax) tree.

But consider this example:

    {
      "a": /* directive */ 42,
      "b": 42, // directive
      // directive
      "d": 42,
      /* directive */ "d": 42
    }

What does the code look like that has to reconcile the directive with the data it modifies?

That's a completely different and worse problem than someone "abusing a string" with something like `{ "a": "42 directive" }`.

I think JSON made the right call. People just confuse that with it being somehow forbidden to use comments in JSON config, but they're wrong. Just look at VSCode's config. It was possible all along despite decades of people whining in blogs.

We didn't need comments in JSON over the wire. We didn't need a new format. We didn't need another blog post about it. Just write your tool to accept comments in its config.

[Vampiero]

I don't understand what the problem is.

You can just make a parser that ignores comments, while still allowing them in the syntax. You don't need to store the comments in the AST, or to actually parse them. You just need to skip them.

[pavlov]

That only works if you control the data that gets parsed.

Imagine you’re a HTML parser library author in 1998. You’ve been happily skipping comments. Now you get complaints that your parser doesn’t see JavaScript. Turns out that everyone has agreed that these new script tags should be embedded inside comments.

Should you keep skipping comments and tell your users you’ll never support this HTML that everybody else now considers valid?

[suby]

Should we not allow comments in HTML, then?

There are parsers which allow for comments if one wants, so if someone wants to engineer an insane system no one is stopping them, provided they can ensure the parser on the other end of it.

This is a data format meant to be readable by humans. As such, it's natural to want to support things like configuration via end-user editing values in the text as a use case. Data is occasionally going to need comments to explain valid options or add context for people to edit. This is a reasonable thing to have.

[fkyoureadthedoc]

Why would a comment be required for this when they can just use a string property? YAML has comments, and they are not used by any DSL abomination that I'm aware of.

[takluyver]

Conda package recipes have a preprocessor using "selectors" in comments to conditionally exclude certain lines in a YAML file. Not that this is particularly more ugly than other YAML DSLs, but it has been used.

[samatman]

Definitely. It's important that every ad-hoc out-of-band data format look

   "like this"

never

   // Like this

Bad Things will surely befall us if we break the taboo.

[eclectic29]

Yes, but you expect much better from a seasoned engineer.

[pointlessone]

We should’ve kept XML.

[berkes]

I keep repeating this.

We already have XML. Stop trying to make JSON another XML.

I'm now knee-deep in a gig that uses all sorts of w3c standards, which enforce json-ld, json-schema, json-whatnots and so on. It's a terrible mess of unreadable complexity that has LONG been solved in XML. Decades ago!

I keep thinking that if you need one of those "fancy" features, why not just use XML? Why bolt them onto JSON, a format that was deliberately (?) set up to not have all these features?

I think that if you don't need these features: by all means, use JSON. It's simpler, cleaner, easier. But that it's only simpler, cleaner, easier because it's not XML. And that all these attempts at making it XML, end up with a JSON that's harder, more complex and often messier than the XML that we had for decades and that JSON tried to "solve" by being simpler. So it's one step forward, two steps back.

[croo]

Right? People forget history faster than ever.

[eadmund]

We should’ve kept S-expressions!

[fullstackwife]

and also life of LLMs would be so much easier, all the JSON content, so much missing context!