3 ms·

JSON is usually the least bad option for machine-readable output formats

2 points by goranmoomin 2y ago

3np 2y ago
One of these days I should write a "Falsehood programmers believe about JSON" piece... The two major pain-points with JSON I see recurring and causing issues: - You need to process the entire document before you can (de)serialize. It's not rare to see pathological cases of this resulting in 100~1000x resource requirements compared to a simpler line-based format like CSV/TSV/0xFFSV. Streaming JSON deserialization can only be achieved to limited extent by "JSONL" (concatenating documents on the root level instead of wrapping them in an array). - Numbers are floating point. The only way to reliably represent decimal numbers is by wrapping them as strings. - You can not rely on the consistency of a hash of the JSON-serialization as it's not well-defined and varies between implementations. You need to specify a well-defined strict subset of JSON with custom serialization if you want this (at this point, are you really reaping the benefits of JSON?). I've seen this one resulting in entire protocols/stacks being rewritten from the ground up due to inability to get required interop working.
- necovek 2y ago
  > You need to process the entire document before you can (de)serialize Really? How so? What does JSON do so differently to what seems to be a much more complex format of XML which has streaming parsers (eg. libxml2 push parser perusing SAX callbacks)? Without thinking hard, a parsed JSON document is easy to parse and serialize back up to any point you got the data for. I am guessing what you mean is that you can't easily read from the middle (you'd have to parse both backwards and forwards), but for any tree like structure, I don't see how you can avoid that (eg. CSV can't encode hierarchical structures). I do agree on point 2: low amount of native data formats really does such (I'd add date-time/timestamp to the list too).

3 ms·

JSON is usually the least bad option for machine-readable output formats

2 points by goranmoomin 2y ago

3np 2y ago
One of these days I should write a "Falsehood programmers believe about JSON" piece... The two major pain-points with JSON I see recurring and causing issues: - You need to process the entire document before you can (de)serialize. It's not rare to see pathological cases of this resulting in 100~1000x resource requirements compared to a simpler line-based format like CSV/TSV/0xFFSV. Streaming JSON deserialization can only be achieved to limited extent by "JSONL" (concatenating documents on the root level instead of wrapping them in an array). - Numbers are floating point. The only way to reliably represent decimal numbers is by wrapping them as strings. - You can not rely on the consistency of a hash of the JSON-serialization as it's not well-defined and varies between implementations. You need to specify a well-defined strict subset of JSON with custom serialization if you want this (at this point, are you really reaping the benefits of JSON?). I've seen this one resulting in entire protocols/stacks being rewritten from the ground up due to inability to get required interop working.
- necovek 2y ago
  > You need to process the entire document before you can (de)serialize Really? How so? What does JSON do so differently to what seems to be a much more complex format of XML which has streaming parsers (eg. libxml2 push parser perusing SAX callbacks)? Without thinking hard, a parsed JSON document is easy to parse and serialize back up to any point you got the data for. I am guessing what you mean is that you can't easily read from the middle (you'd have to parse both backwards and forwards), but for any tree like structure, I don't see how you can avoid that (eg. CSV can't encode hierarchical structures). I do agree on point 2: low amount of native data formats really does such (I'd add date-time/timestamp to the list too).