6 ms·

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":

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 3y 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 3y 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 3y 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 3y 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}

wizzwizz4 3y 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 3y 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 3y 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 3y 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}