6 ms·

JSON is fairly trivial. The post is a nonsensical rant about parsers accepting non-JSON compliant documents (as the JSON spec specifically states that parsers m

JSON is fairly trivial. The post is a nonsensical rant about parsers accepting non-JSON compliant documents (as the JSON spec specifically states that parsers may), such as trailing commas. In the large colored matrix, the following colors mean everything is fine: Green, yellow, light blue and deep blue. Red are crashes (things like 10000 nested arrays causing a stack overflow—this is a non-JSON-specific parser bug), and dark brown are constructs that should have been supported but weren't (things like UTF-8 handling, which is again non-JSON specific parser bugs). Writing parsers can be tricky, but JSON is certainly not a hard format to parse.

SamReidHughes 9y ago
As a question of fact, programs put out JSON that gets misparsed by other programs. Some simply parse floating point values differently, or they treat Unicode strings incorrectly, or output them incorrectly. Different parsers have different opinions about what a document represents. This has a real world impact. Accepting invalid or ambiguous or undefined JSON is not an acceptable behavior. It means bugs get swallowed up and you can't reliably round trip data.
- repsilat 9y ago
  > Accepting invalid or ambiguous or undefined JSON is not an acceptable behavior Just to make it explicit (and without inserting any personal judgement into the conversation myself): JSON parsers should reject things like trailing commas after final array elements because it will encourage people to emit trailing commas? Having asked the question (and now explicitly freeing myself to talk values) it's new to me -- a solid and rare objection to the Robustness Principle. Maybe common enough in these sorts of discussions, though? Anyway, partial as I might be to trailing commas, I do quite like the "JSON's universality shall not be compromised" argument.
  - SamReidHughes 9y ago
    Postel's Law or the "Robustness Principle" is an anti-pattern in general. Accepting trailing commas in JSON isn't as big a deal as having two different opinions about what a valid document is. But you might think a trailing comma could indicate a hand-edited document that's missing an important field or array element.
- arghwhat 9y ago
  Unicode and floating point misparsing are not even remotely JSON related, but are simply bugs that can occur in any parser that handles unicode or floating point. Thus, complaining about it in a "JSON is a minefield" thread is a bit silly. If you put out JSON that gets misparsed, you either generated invalid JSON, or the parser is faulty. Nothing around that. This has nothing to do with whether parsers have flexibility to accept additional constructs, which is extremely common for a parser to do.
Annatar 9y ago
Actually unless one is doing JavaScript, JSON is extremely difficult to parse correctly. I challenge you to write a simple, understandable JSON parser in Bourne shell or in AWK.
- repsilat 9y ago
  > JSON is extremely difficult to parse correctly ... in Bourne shell or in AWK. Sorry for the misquote, but does it get to the heart of your objection? I'm torn here. On the one hand I want to say "Those are not languages one typically writes parsers in," but that's a really muddled argument: 1. People "parse" things often in bash/awk because they have to -- because bash etc deal in unstructured data. 2. Maybe "reasonable" languages should be trivially parseable so we can do it in Bash (etc). I'm kinda torn. On the one hand bash is unreasonably effective, on the other I want data types to be opaque so people don't even try to parse them... would love to hear arguments though.
  - arghwhat 9y ago
    You definitely shouldn't write a parser for anything in bash. If you want to deal with JSON, I'd recommend jq as an easy manipulation tool.
    - Annatar 9y ago
      I wrote Bourne shell and both of you assumed bash. Horrid state of affairs in today’s IT. All hail Linux hegemony! And AWK, if it’s not easily parsable with the language specifically designed for parsing data, something is wrong with that data.
  - Annatar 9y ago
    Shell and AWK programs have fewest dependencies, are extremely light on resources’ consumption and are extremely fast. When someone’s program emits JSON because the author assumed that programs which ingest that data will also be JavaScript programs, that’s a really bad assumption. It would force the consumer of that data to replicate the environment. This goes against core UNIX principles, as discussed at length in “The art of UNIX programming” book. It’s a rookie mistake to make.

SamReidHughes 9y ago

As a question of fact, programs put out JSON that gets misparsed by other programs. Some simply parse floating point values differently, or they treat Unicode strings incorrectly, or output them incorrectly. Different parsers have different opinions about what a document represents. This has a real world impact. Accepting invalid or ambiguous or undefined JSON is not an acceptable behavior. It means bugs get swallowed up and you can't reliably round trip data.

repsilat 9y ago
> Accepting invalid or ambiguous or undefined JSON is not an acceptable behavior Just to make it explicit (and without inserting any personal judgement into the conversation myself): JSON parsers should reject things like trailing commas after final array elements because it will encourage people to emit trailing commas? Having asked the question (and now explicitly freeing myself to talk values) it's new to me -- a solid and rare objection to the Robustness Principle. Maybe common enough in these sorts of discussions, though? Anyway, partial as I might be to trailing commas, I do quite like the "JSON's universality shall not be compromised" argument.
- SamReidHughes 9y ago
  Postel's Law or the "Robustness Principle" is an anti-pattern in general. Accepting trailing commas in JSON isn't as big a deal as having two different opinions about what a valid document is. But you might think a trailing comma could indicate a hand-edited document that's missing an important field or array element.
arghwhat 9y ago
Unicode and floating point misparsing are not even remotely JSON related, but are simply bugs that can occur in any parser that handles unicode or floating point. Thus, complaining about it in a "JSON is a minefield" thread is a bit silly. If you put out JSON that gets misparsed, you either generated invalid JSON, or the parser is faulty. Nothing around that. This has nothing to do with whether parsers have flexibility to accept additional constructs, which is extremely common for a parser to do.

Annatar 9y ago

Actually unless one is doing JavaScript, JSON is extremely difficult to parse correctly. I challenge you to write a simple, understandable JSON parser in Bourne shell or in AWK.

repsilat 9y ago
> JSON is extremely difficult to parse correctly ... in Bourne shell or in AWK. Sorry for the misquote, but does it get to the heart of your objection? I'm torn here. On the one hand I want to say "Those are not languages one typically writes parsers in," but that's a really muddled argument: 1. People "parse" things often in bash/awk because they have to -- because bash etc deal in unstructured data. 2. Maybe "reasonable" languages should be trivially parseable so we can do it in Bash (etc). I'm kinda torn. On the one hand bash is unreasonably effective, on the other I want data types to be opaque so people don't even try to parse them... would love to hear arguments though.
- arghwhat 9y ago
  You definitely shouldn't write a parser for anything in bash. If you want to deal with JSON, I'd recommend jq as an easy manipulation tool.
  - Annatar 9y ago
    I wrote Bourne shell and both of you assumed bash. Horrid state of affairs in today’s IT. All hail Linux hegemony! And AWK, if it’s not easily parsable with the language specifically designed for parsing data, something is wrong with that data.
- Annatar 9y ago
  Shell and AWK programs have fewest dependencies, are extremely light on resources’ consumption and are extremely fast. When someone’s program emits JSON because the author assumed that programs which ingest that data will also be JavaScript programs, that’s a really bad assumption. It would force the consumer of that data to replicate the environment. This goes against core UNIX principles, as discussed at length in “The art of UNIX programming” book. It’s a rookie mistake to make.