5 ms·

For machine to machine interchange formats, removing redundant elements is reasonable, but for formats that are meant to be read (and more critically, edited) b

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.

capableweb 4y ago
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.
- wizzwizz4 4y ago
  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.
  - djedr 4y ago
    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 https://news.ycombinator.com/item?id=35675811
  - capableweb 4y ago
    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.
    - wizzwizz4 4y ago
      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}

capableweb 4y ago

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.

wizzwizz4 4y ago
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.
- djedr 4y ago
  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 https://news.ycombinator.com/item?id=35675811
- capableweb 4y ago
  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.
  - wizzwizz4 4y ago
    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}