Hacker News Reader

Comment by wizzwizz4 | Hacker News Reader

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.

View on HN

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