4 ms·

For you, perhaps. For me, the former is denser, but crossing into a "too dense" region. The JSON has indentation which is easy on my poor brain. Also, it's nice

For you, perhaps. For me, the former is denser, but crossing into a "too dense" region. The JSON has indentation which is easy on my poor brain. Also, it's nice to differentiate between lists and objects. But, I mean, they're basically isomorphic with like 2 things exchanges ({} and [] instead of (); implicit vs explicit keys/types).

josephg 1y ago
Yeah. I don’t even blame S-expressions. I think I’ve just been exposed to so much json at this point that my visual system has its own crappy json parser for pretty-printed json. S expressions may well be better. But I don’t think S expressions are better enough to be able to overcome json’s inertia.
em-bee 1y ago
even as a fan of s-expressions (see my other comment), i have to agree. but the problem here is the formatting. for starters, i would write the s-expression example as: (urn:ietf:params:acme:error:malformed (detail "Some of the identifiers requested were rejected") (subproblems ((urn:ietf:params:acme:error:malformed (detail "Invalid underscore in DNS name \"_example.org\"") (identifier (dns _example.org))) (urn:ietf:params:acme:error:rejectedIdentifier (detail "This CA will not issue for \"example.net\"") (identifier (dns example.net)))))) the alignment of the values makes them easier to pick out and gives a visual structure but, i would also argue that the two examples are not equivalent. what is explicitly specified as "type" and "value" in the json data, is implied in the s-expression data. either format is fine, but it would be better to compare like for like: an s-expression equivalent for the json example would look like this: ((type urn:ietf:params:acme:error:malformed) (detail "Some of the identifiers requested were rejected) (subproblems ((type urn:ietf:params:acme:error:malformed) (detail "Invalid underscore in DNS name \"_example.org\"") (identifier (type dns) (value _example.org))) ((type urn:ietf:params:acme:error:rejectedIdentifier) (detail "This CA will not issue for \"example.net\"") (identifier (type dns) (value example.net))))) or the reverse, a json equivalent for the s-expression example: { "urn:ietf:params:acme:error:malformed": { "detail": "Some of the identifiers requested were rejected", "subproblems": [ "urn:ietf:params:acme:error:malformed": { "detail": "Invalid underscore in DNS name \"_example.org\"", "identifier": { "dns": "_example.org" } }, "urn:ietf:params:acme:error:rejectedIdentifier" { "detail": "This CA will not issue for \"example.net\"", "identifier": { "dns": "example.net" } } ] } } a lot of the readability depends on the formatting. we could format the json example more dense: {"urn:ietf:params:acme:error:malformed": { "detail": "Some of the identifiers requested were rejected", "subproblems": [ "urn:ietf:params:acme:error:malformed": { "detail": "Invalid underscore in DNS name \"_example.org\"", "identifier": { "dns": "_example.org" }}, "urn:ietf:params:acme:error:rejectedIdentifier": { "detail": "This CA will not issue for \"example.net\"", "identifier": { "dns": "example.net" }}]}} doing that shows that the main problem that makes json harder to read is the quotes around strings. because if we spread out the s-expression example: (urn:ietf:params:acme:error:malformed (detail "Some of the identifiers requested were rejected") (subproblems ((urn:ietf:params:acme:error:malformed (detail "Invalid underscore in DNS name \"_example.org\"") (identifier (dns _example.org) ) ) (urn:ietf:params:acme:error:rejectedIdentifier (detail "This CA will not issue for \"example.net\"") (identifier (dns example.net) ) ) ) ) ) that doesn't add much to the readability. since, again, the primary win in readability comes from removing the quotes.

josephg 1y ago

Yeah. I don’t even blame S-expressions. I think I’ve just been exposed to so much json at this point that my visual system has its own crappy json parser for pretty-printed json. S expressions may well be better. But I don’t think S expressions are better enough to be able to overcome json’s inertia.

em-bee 1y ago

even as a fan of s-expressions (see my other comment), i have to agree. but the problem here is the formatting. for starters, i would write the s-expression example as: (urn:ietf:params:acme:error:malformed (detail "Some of the identifiers requested were rejected") (subproblems ((urn:ietf:params:acme:error:malformed (detail "Invalid underscore in DNS name \"_example.org\"") (identifier (dns _example.org))) (urn:ietf:params:acme:error:rejectedIdentifier (detail "This CA will not issue for \"example.net\"") (identifier (dns example.net)))))) the alignment of the values makes them easier to pick out and gives a visual structure but, i would also argue that the two examples are not equivalent. what is explicitly specified as "type" and "value" in the json data, is implied in the s-expression data. either format is fine, but it would be better to compare like for like: an s-expression equivalent for the json example would look like this: ((type urn:ietf:params:acme:error:malformed) (detail "Some of the identifiers requested were rejected) (subproblems ((type urn:ietf:params:acme:error:malformed) (detail "Invalid underscore in DNS name \"_example.org\"") (identifier (type dns) (value _example.org))) ((type urn:ietf:params:acme:error:rejectedIdentifier) (detail "This CA will not issue for \"example.net\"") (identifier (type dns) (value example.net))))) or the reverse, a json equivalent for the s-expression example: { "urn:ietf:params:acme:error:malformed": { "detail": "Some of the identifiers requested were rejected", "subproblems": [ "urn:ietf:params:acme:error:malformed": { "detail": "Invalid underscore in DNS name \"_example.org\"", "identifier": { "dns": "_example.org" } }, "urn:ietf:params:acme:error:rejectedIdentifier" { "detail": "This CA will not issue for \"example.net\"", "identifier": { "dns": "example.net" } } ] } } a lot of the readability depends on the formatting. we could format the json example more dense: {"urn:ietf:params:acme:error:malformed": { "detail": "Some of the identifiers requested were rejected", "subproblems": [ "urn:ietf:params:acme:error:malformed": { "detail": "Invalid underscore in DNS name \"_example.org\"", "identifier": { "dns": "_example.org" }}, "urn:ietf:params:acme:error:rejectedIdentifier": { "detail": "This CA will not issue for \"example.net\"", "identifier": { "dns": "example.net" }}]}} doing that shows that the main problem that makes json harder to read is the quotes around strings. because if we spread out the s-expression example: (urn:ietf:params:acme:error:malformed (detail "Some of the identifiers requested were rejected") (subproblems ((urn:ietf:params:acme:error:malformed (detail "Invalid underscore in DNS name \"_example.org\"") (identifier (dns _example.org) ) ) (urn:ietf:params:acme:error:rejectedIdentifier (detail "This CA will not issue for \"example.net\"") (identifier (dns example.net) ) ) ) ) ) that doesn't add much to the readability. since, again, the primary win in readability comes from removing the quotes.