Personally, I really hope Human JSON, https://github.com/tailscale/hujson , will get more popular!
https://www.freecodecamp.org/news/comments-in-json/
They were removed from the standard because some were using them for custom parser directives.
Who wants to type `{name: "pveierland"}` when you could just do `{name "pveierland"}`?!
`{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) 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.
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.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.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=35675811With 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.
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}