5 ms·

I still don't get what the point of json is. If you want to dump raw JS data structures as text just do. You don't need a spec or special tools. If you want hum

I still don't get what the point of json is. If you want to dump raw JS data structures as text just do. You don't need a spec or special tools. If you want human readable XML just use s-expressions. Something that's so easy to parse you can roll your own in an afternoon. Json is trying to square the circle of "I want things to be easy" but also "I want to not shoot myself in the foot", goals which are mutually exclusive. Every new version of json is just gods way of teaching people how XML got to be the mess it is.

t0astbread 4y ago
If I wanted to dump raw JS data structures as text the most straightforward way I can think of is `JSON.stringify` and `JSON.parse`. No need to roll your own S-expression parser.
- thrown_22 4y ago
  console.log(a) eval(a)
TylerE 4y ago
Shockingly about 98% of the population doesn't find massive mounds of nested parens especially readable.
- thrown_22 4y ago
  But make the brackets curly and it's fine.
  - TylerE 4y ago
    Curly bracket languages don't require braces around every statement. If C was written like {if {x == 1}{ {return {x + 1};} } Maybe you'd have a point
    - thrown_22 4y ago
      That's nice, but we're not talking about con, we're talking about json. Also your syntax is terrible. There are already s-expression versions of c: (if (== x 1) (return (+ x 1)))
- AnimalMuppet 4y ago
  But massive mounds of </this_tag></that_tag></the_other_tag></yet_another_tag> is readable? I mean, I guess you know what each tag is closing, which is more than you get with ))))...
  - chris_wot 4y ago
    It kind of is, actually.
lmm 4y ago
"s-expressions" is vaporware. Everyone who says it has a slightly different format in mind. It's easy to be all things to all people when you don't have to actually implement anything.
- thrown_22 4y ago
  Every lisp program supports that serialization format out of the box.
  - lmm 4y ago
    No, every lisp program supports its own idiosyncratic variation on it, no two alike.
    - thrown_22 4y ago
      Yes, just how no two json implementations support the same schema.
      - lmm 4y ago
        Independent JSON implementations can parse and manipulate the same files, since they agree on what the basic datatypes are. S-expression implementations don't; often they don't even agree on what the quoting convention is.
        thrown_22 4y ago
        >since they agree on what the basic datatypes are That is not the job of the data format, that is the job of the meta data format. That this is still a draft tells you how far behind json is: https://json-schema.org/draft/2020-12/json-schema-core.html https://json-schema.org/draft/2020-12/json-schema-core.html Again, json is gods way of teaching bad devs why xml is such a mess.
        lmm 4y ago
halayli 4y ago
No, these goals aren't mutually exclusive and I am not sure where "shoot myself in the foot" fits here. It's a serialization format and has many practical use cases. At least back your claims with concrete examples. There's only a single JSON ISO standard (21778:2017). Why do you feel compelled to comment on topics you don't have knowledge about?
- thrown_22 4y ago
  You're posting this in a thread about json5. Clearly there isn't just one json standard.

t0astbread 4y ago

If I wanted to dump raw JS data structures as text the most straightforward way I can think of is `JSON.stringify` and `JSON.parse`. No need to roll your own S-expression parser.

thrown_22 4y ago
console.log(a) eval(a)

TylerE 4y ago

Shockingly about 98% of the population doesn't find massive mounds of nested parens especially readable.

thrown_22 4y ago
But make the brackets curly and it's fine.
- TylerE 4y ago
  Curly bracket languages don't require braces around every statement. If C was written like {if {x == 1}{ {return {x + 1};} } Maybe you'd have a point
  - thrown_22 4y ago
    That's nice, but we're not talking about con, we're talking about json. Also your syntax is terrible. There are already s-expression versions of c: (if (== x 1) (return (+ x 1)))
AnimalMuppet 4y ago
But massive mounds of </this_tag></that_tag></the_other_tag></yet_another_tag> is readable? I mean, I guess you know what each tag is closing, which is more than you get with ))))...
- chris_wot 4y ago
  It kind of is, actually.

lmm 4y ago

"s-expressions" is vaporware. Everyone who says it has a slightly different format in mind. It's easy to be all things to all people when you don't have to actually implement anything.

thrown_22 4y ago
Every lisp program supports that serialization format out of the box.
- lmm 4y ago
  No, every lisp program supports its own idiosyncratic variation on it, no two alike.
  - thrown_22 4y ago
    Yes, just how no two json implementations support the same schema.
    - lmm 4y ago
      Independent JSON implementations can parse and manipulate the same files, since they agree on what the basic datatypes are. S-expression implementations don't; often they don't even agree on what the quoting convention is.
      - thrown_22 4y ago
        >since they agree on what the basic datatypes are That is not the job of the data format, that is the job of the meta data format. That this is still a draft tells you how far behind json is: https://json-schema.org/draft/2020-12/json-schema-core.html https://json-schema.org/draft/2020-12/json-schema-core.html Again, json is gods way of teaching bad devs why xml is such a mess.
        lmm 4y ago

halayli 4y ago

No, these goals aren't mutually exclusive and I am not sure where "shoot myself in the foot" fits here. It's a serialization format and has many practical use cases. At least back your claims with concrete examples. There's only a single JSON ISO standard (21778:2017). Why do you feel compelled to comment on topics you don't have knowledge about?

thrown_22 4y ago
You're posting this in a thread about json5. Clearly there isn't just one json standard.