I appreciate Phil’s writing much of the time, but in this particular case I believe that he is very wrong. The whole point of JSON is that it is an object nota

I appreciate Phil’s writing much of the time, but in this particular case I believe that he is very wrong. The whole point of JSON is that it is an object notation: JSON parses into a kind of lowest-common-denominator object, either a number, a string, an array, a hash table, a boolean or a null. Every language supports those, one way or another. You can read an object into your runtime, mutate it, then print it back out and only the mutated part will change (this is round-tripping). If comments were added, then to preserve round-trippability they would need to be readable. For that to work, they would need to live somewhere in the read-in object. But then, what would the result of reading this be? 3.14 # pi It can’t be 3.14; it has to be something like [3.14, #<COMMENT: "pi">]. What even is a comment object? Where would the comment go in an example like this? { "foo": "bar" # baz } Maybe the returned object is something like {"foo": #<COMMENTED-VALUE: "bar" " baz"}? But what is that type? It’s a huge can of worms! Sure, you could just give up on roundtripping. But it’s important! XML of course has support for comments, but they are objects within its infoset: when you read in an XML document, you can access the comments as part of it. One of the points of JSON is that one doesn’t need all the complexity of XML to get stuff done.