4 ms·

Oops, I accidentally selected a couple of bits and hit delete… EDN [{ "0003" "type" "donut" "name" "Old Fashioned" "ppu" 0.55 "batters"

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}

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}