3 ms·

> I think it's pretty obvious which one is cleaner … Yes, clearly it's the JSON. How do you tell at a glance in the s-expr formatted data what's an object and

by shawnz 7y ago

> I think it's pretty obvious which one is cleaner … Yes, clearly it's the JSON. How do you tell at a glance in the s-expr formatted data what's an object and what's an array? What's a keyword and what's a literal? I can barely even tell the heirarchy where it's very visually obvious with the JSON.

frenchyatwork 7y ago
I have no strong love for s-expressions, but objects and arrays are programming language constructs, not data format constructs. There's also no way in JSON to distinguish between an int and a float and a decimal type, but that's fine because it's a data format, and not a programming language literal. The JSON and s-expr have a different indent level, which is why the hierarchy is less obvious to you.
- shawnz 7y ago
  > objects and arrays are programming language constructs, not data format constructs. Debatable. To me there is a clear difference between a list of things of the same type, and a mapping of names to values of potentially varying types. I don't think the specific programming language really matters, they are two totally different concepts with much different applications. > There's also no way in JSON to distinguish between an int and a float and a decimal type True, but they are just small literals which are easy to differentiate at a glance, not big multi-line structures like objects or lists. Plus s-expressions have the same issue.
zeveb 7y ago
> what's an object and what's an array? There are no objects — it's all lists (or arrays, if you prefer). This is a good thing, because ordering is always the same. > What's a keyword and what's a literal? Everything's a byte string: any interpretation above that is a matter for the protocol. This is a good thing, because it means you neatly sidestep issues like JSON's numbers actually being floats rather than integers, as well as issues like numeric precision. 'But I want types!' Of course, they are good. But the type of a number isn't just integer or float: it's integer-which-is-a-known-version or float-which-is-between-zero-and-one-exclusive. You need to check those types at ingestion anyway; it's not a big leap from integer-which-is-a-known-version to string-which-parses-as-an-integer-which-is-a-known-version. > I can barely even tell the heirarchy where it's very visually obvious with the JSON. They are both indicated with indentation. Probably I should have used two spaces for the JSON indentation, but I was lazy.

by shawnz 7y ago

frenchyatwork 7y ago

I have no strong love for s-expressions, but objects and arrays are programming language constructs, not data format constructs. There's also no way in JSON to distinguish between an int and a float and a decimal type, but that's fine because it's a data format, and not a programming language literal. The JSON and s-expr have a different indent level, which is why the hierarchy is less obvious to you.

shawnz 7y ago
> objects and arrays are programming language constructs, not data format constructs. Debatable. To me there is a clear difference between a list of things of the same type, and a mapping of names to values of potentially varying types. I don't think the specific programming language really matters, they are two totally different concepts with much different applications. > There's also no way in JSON to distinguish between an int and a float and a decimal type True, but they are just small literals which are easy to differentiate at a glance, not big multi-line structures like objects or lists. Plus s-expressions have the same issue.

zeveb 7y ago

> what's an object and what's an array? There are no objects — it's all lists (or arrays, if you prefer). This is a good thing, because ordering is always the same. > What's a keyword and what's a literal? Everything's a byte string: any interpretation above that is a matter for the protocol. This is a good thing, because it means you neatly sidestep issues like JSON's numbers actually being floats rather than integers, as well as issues like numeric precision. 'But I want types!' Of course, they are good. But the type of a number isn't just integer or float: it's integer-which-is-a-known-version or float-which-is-between-zero-and-one-exclusive. You need to check those types at ingestion anyway; it's not a big leap from integer-which-is-a-known-version to string-which-parses-as-an-integer-which-is-a-known-version. > I can barely even tell the heirarchy where it's very visually obvious with the JSON. They are both indicated with indentation. Probably I should have used two spaces for the JSON indentation, but I was lazy.