Hacker News Reader

Comment by capableweb | Hacker News Reader

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.

View on HN

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