4 ms·

I'd argue that JSON is one of the least Human Readable serialization formats. It lacks comments. Has no way to offer context. Cannot impose limitations, and no

• codeflo 4y ago
  1. I 100% agree about comments. 2. I’m still not convinced it’s the file format’s job to encode every possible data type. We used to have deserialization layers for that, but for some reason, we don’t do that anymore. Nowadays we expect every file format to be self-describing, which I think is wasteful and limiting. But that’s a matter of opinion, obviously. 3. What do you mean by “cannot be parsed streaming”? Or to be perhaps more precise, what’s missing in existing streaming JSON parsers? I haven’t used any of them yet.
  • mxmlnkn 4y ago
    Many JSON parsers require the whole JSON file to be in memory. Parsers that allow parsing in streaming manner are the exception. I only found jsoncons to work reliable but at the cost of speed compared to something fast like rapidjson. And even jsoncons might have the problem that large strings have to be fully in memory, i.e., if someone has the fun idea to store a 1 GB string inside a JSON, then you still have a potential out-of-memory event at your hand. There are other attempts to fix this problem with the jsonl format but that format feels so ad-hoc that I'm not convinced yet. It stores one JSON object per line. Of course, this comes with its own problems such as each JSON object potentially still being unbounded and, now that lines are used to separate JSON objects, you cannot format those JSON objects in a human-readable way anymore. Also, the first time I encountered a file like this, it simply had a .json extension and I was wondering why every JSON parser failed to parse that file. Because it isn't valid JSON and should have a separate extension.
    • tlavoie 4y ago
      Streaming parsers may be the exception, but are likely the correct tool to use when handling large inputs becomes a problem. Similarly, XML parsers evolved the SAX model (as opposed to DOM, where the document had to fit in memory.) It is often sufficient to rip through the file in an event-based fashion to extract what you want, and throw the rest away. For cases where a single string is truly massive, I would lean towards defining a maximum size to prevent denial of service attacks.
  • berkes 4y ago
    3. Like sibling comment or said: most parsers need the entire file (in memory) before being able to start parsing. XML is just as bad here: both, technically, need the parser to see the closing part before being able to parse the chunk.
• IshKebab 4y ago
  The lack of comments isn't really a big deal for serialisation. Nobody is really going to bother adding comments when data is serialised. You could do that with XML if you wanted and I have never seen a single occurrence. The issue is that JSON ended up being used as a configuration format too, and comments are critical there. JSON5 is the best answer I have found.
• koito17 4y ago
  EDN at least provides date literals, UUID literals, and decimals. It also does not require commas to be littered everywhere. Unfortunately EDN is only really well-supported within Clojure. I'm not sure what is meant by "context problem" for JSON, but keywords and symbols in EDN can be namespaced, so that one can distinguish e.g. :human/name and :computer/name. However, it still requires you to write a schema. And due to lack of support in other languages, protocol buffers seem to be a much better choice.
  • berkes 4y ago
    Context being "this branch is a link" or "this string is a creditcard-number" or "this employee here is-a Title-over there, at Company over there".
• kordlessagain 4y ago
  Then I guess the same is for all these dicts I use in Python.
• Someone 4y ago
  > as it lacks crucial types (datetime, decimal) Decimal is there, isn’t it, as part of ‘number’, which lumps together fixed-size integers, IEEE floats and doubles, bigints and bigfloats, and leaves it to the parser to make the right guess as to how to interpret them (often assisted by having the programmer specify a target data type)? Lumping all those together as ‘number’ makes for a much simpler grammar, but I think that’s not worth it for its negative effects on interoperability. How many json parsers can (easily) read a value of 1234567890123456890E0000000001 and write back the same string to a json file? Apart from datetime, I’d add duration as a basic type, too, even though that has the problem of being imprecise. Users will want to specify durations such as “1m” or “1y” (is that 365 days? 365.2425 to correct for leap years? Does it depend on interpretation by the user? is it a lunar year of 354/355 days as in the Islamic calendar? Etc)
• berniedurfee 4y ago
  Agreed. Lack of comments and lack of proper schema enforcement makes JSON a junk pile of a data format. Definitely not an improvement over XML. Hopefully the next popular standard data format will learn from the past and take the best of previous attempts.
  • tristan957 4y ago
    JSON has schemas though. I use them all the time.
    • berkes 4y ago
      JSON itself (rfc 8259) has no schema, nor any mention of it. There are several additional RFCs that allow to add schema or other semantics or limitations, though. But JSON has no schemas.
      • smcin 4y ago
        I think you mean "the JSON standard doesn't define any schema".
        • berkes 4y ago
          Indeed. Nor does it mention any place, extension or addition where a scheme could be defined.
  • kbelder 4y ago
    The problem is, that despite JSON's clear and numerous flaws, people still overwhelmingly prefer it to XML. XML is that unpleasant.