3 ms·

Alien is not a reason something is bad, just that's it's unusual. JSON was a bit alien when it first arrived as well, as everyone was used to XML at the time.

Alien is not a reason something is bad, just that's it's unusual. JSON was a bit alien when it first arrived as well, as everyone was used to XML at the time. `{num 5, val 4}` looks fine to me, but we can do even better! We already know objects/maps are always in pairs, so we don't really need that comma either. Just do `{num 5 val 4}` and we save yet another unnecessary characters. Of course, I didn't come up with this format myself, what I actually want JSON to be is EDN (https://github.com/edn-format/edn https://github.com/edn-format/edn) which is a standalone format but also directly used in Clojure, so it already exists inside a programming language and works very well. There keys are strings though, so you example would end up being `{"num" 5 "val" 5 "person" var}`, where commas are optional.

estebank 3y ago
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 3y 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 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.

estebank 3y ago

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