Hacker News Reader

Comment by capableweb | Hacker News Reader

Alien is not a reason something is bad, just that's it's unusual. JSON was a bit alien when it first arrived as well, as everyone was used to XML at the time.

`{num 5, val 4}` looks fine to me, but we can do even better! We already know objects/maps are always in pairs, so we don't really need that comma either. Just do `{num 5 val 4}` and we save yet another unnecessary characters.

Of course, I didn't come up with this format myself, what I actually want JSON to be is EDN (https://github.com/edn-format/edn) which is a standalone format but also directly used in Clojure, so it already exists inside a programming language and works very well. There keys are strings though, so you example would end up being `{"num" 5 "val" 5 "person" var}`, where commas are optional.

View on HN

For machine to machine interchange formats, removing redundant elements is reasonable, but for formats that are meant to be read (and more critically, edited) by humans it is better to have syntactical redundancy. It makes it easier to scan documents and much, much easier to provide human-friendly parser errors when we inevitably make mistakes. The redundancy works as flagposts that both machines and humans can use to get their bearings even in the face of malformed input.

I think it's highly subjective what's easier for humans to read/write.

Personally, I much prefer the latter of these two:

JSON:

    [
      {
          "id":"0003",
          "type":"donut",
          "name":"Old Fashioned",
          "ppu":0.55,
          "batters":{
            "batter":[
                {
                  "id":"1001",
                  "type":"Regular"
                }
            ]
          },
          "topping":[
            {
                "id":"5004",
                "type":"Maple"
            }
          ]
      }
    ]

EDN

    [{"id" "0003"
      "type" "donut"
      "name" "Old Fashioned"
      "ppu" 0.55
      "batters" {"batter" [{"id" "1001"
                            "type" "Regular"}]}
      "topping" [{"id" "5004"
                  "type" "Maple"}]}]

Strings (like `"id"`) are usually keywords (like `:id`) in EDN, but I still find it much easier to parse and understand. I've read a lot more JSON over the years than I've read EDN, so I don't think it's a "used to" feeling I have either.

Oops, I accidentally selected a couple of bits and hit delete…

EDN

  [{     "0003"
    "type" "donut"
    "name" "Old Fashioned"
    "ppu" 0.55
    "batters" {"batter" [{"id" "1001"
                          "type" "Regular"}]}
    "topping"
                                }]

This issue occurs even if you use the comma syntax:

  {:id 3, :type, :ppu 0.55, :topping}

parses to:

  {
    :id 3,
    :type :ppu,
    0.55 :topping,
  }

The worst thing a human-readable data format can have is syntax that looks like it's redundant (and capable of error-detection), but is actually ignored.

What if we could have minimal redundancy and still be capable of error detection?

Check this[0] out:

    [
        id [0003]
        type [donut]
        name [Old Fashioned]
        ppu [0.55]
        batters [
            batter [
                [
                    id [1001]
                    type [Regular]
                ]
            ]
        ]
        topping [
            [
                id [5004]
                type [Maple]
            ]
        ]
    ]

Now if we delete `id` we will get a syntax error. And yet no commas, no colons, no quotemarks! Only square brackets. Minimal redundancy.

For a bit more error-checking-thru-redundancy we could analyze indentation (one reason why I recommend C-style rather than Lisp-style formatting) and warn if we detect any inconsistencies.

Ergo: through design magic we can get rid of a lot of the redundancy and increase desirable properties, without trading off much of the positive side.

NB for a machine we could compact the above into:

    [id[0003]type[donut]name[Old Fashioned]ppu[0.55]batters[batter[[id[1001]type[Regular]]]]topping[[id[5004]type[Maple]]]]

[0] More on that here: https://news.ycombinator.com/item?id=35675811

If you actually want error-correction, I don't think either JSON or EDN is suitable for providing that out of the box. You probably want to provide error-correction out of band in that case.

With your argument, JSON is equally bad because you could have {"name": "wizzwizz4", "age": 16} and ooops, some things got deleted and now the structure ends up being {"name": 16} which isn't really a sound argument against the format itself.

With JSON, few typos go undetected, and an (undetected) local typo causes a local error in the data. With EDN, many typos go undetected, and a local typo can cause non-local errors.

Another situation, due to the same defect:

  {:name Jason Bourne, :age 320 000}

The JSON-equivalent mistake would be a syntax error:

  {"name": "Jason Bourne", "age": 320 000}

Reply on news.ycombinator.com