3 ms·

You're missing my point: basically nothing spits out data in that format because it's not ergonomic to do so. JSON is designed to represent object hierarchies,

You're missing my point: basically nothing spits out data in that format because it's not ergonomic to do so. JSON is designed to represent object hierarchies, not tabular data.

koolba 2y ago
JSON was designed to represent any data. There's plenty of systems that spit out data in exact that format because it's the natural way to represent tabular data using JSON serialization. And clearly if you're the one building the system you can choose to use it.
hajile 2y ago
CSV is lists of lists of fixed length. JSON is lists of lists of any length and groups of key/value pairs (basically lisp S-expressions with lots of unnecessary syntax). This makes it a superset of CSV's capabilities. JSON fundamentally IS made to represent tabular data, but it's made to represent key-value groups too. Why make it able to represent tabular data if that's not an intended use?
- meepmorp 2y ago
  > CSV is lists of lists of fixed length. I'd definitely put that in my list of falsehoods programmers believe about CSV files.
  - timacles 2y ago
    CSV is a text file that might have commas in it
    - deleted 2y ago
      [deleted]
  - hajile 2y ago
    It seems to be indicated by RCF-4180 which says > This header will contain names corresponding to the fields in the file and should contain the same number of fields as the records in the rest of the file But of course, CSV is the wild west and there's no guarantee that any two encoders will do the same thing (sometimes, there's not even a guarantee that the same encoder will do the same thing with two different inputs). [0] https://www.ietf.org/rfc/rfc4180.txt https://www.ietf.org/rfc/rfc4180.txt
    - HelloNurse 2y ago
      You should know that "should" isn't very binding. Headers should have as many rows as possible that contain data items for their column and data items in a row should have a header for the respective columns, but real CSV files should be assumed to have incomplete or variable length lines.
      - hajile 2y ago
        NOTHING is very binding about the CSV spec and that's the biggest problem with CSV.
  - miningape 2y ago
    yeah if I had a cookie for every time I've had to deal with this I'd have maybe 10 cookies - it's not a lot but it's more than it should be.
- freehorse 2y ago
  The fact that json can represent a superset of tabular data structures that csv is specifically designed to represent can be rephrased into that csv is more specialised than json in representing tabular data. The fact that json can also represent tabular data does not mean it is a better or more efficient way to represent that data instead of a format like csv. In the same way, there are hierarchically structured datasets that can be represented by both json in hierarchical form and csv in tabular form by repeating certain variables, but if using csv would require repeating them too many times, it would be a bad idea to choose that instead of json. The fact that you can do sth does not always make it a good idea to do it. The question imo is about which way would be more natural, easy or efficient.
  - hajile 2y ago
    It's hardly a bad idea to do a list of lists in JSON... The big advantage of JSON is that it's standardized and you can reuse the JSON infrastructure for more than just tabular data.
  - Kinrany 2y ago
    > The fact that json can represent a superset of tabular data structures that csv is specifically designed to represent can be rephrased into that csv is more specialised than json in representing tabular data. The fact that json can also represent tabular data does not mean it is a better or more efficient way to represent that data instead of a format like csv. The reverse is true as well: being more specialized is a description of goals, not advantages.
- deleted 2y ago
  [deleted]
- packetlost 2y ago
  > JSON is lists of lists of any length and groups of key/value pairs The "top-level" structure of JSON is usually an object, but it can be a list. > JSON fundamentally IS made to represent tabular data No, it's really not. It's made to represent objects consisting of a few primitive types and exactly two aggregate types: lists and objects. It's a textual representation of the JavaScript data model and even has "Object" in the name. > Why make it able to represent tabular data if that's not an intended use? It's mostly a question of specialization and ergonomics, which was my original point. You can represent tabular data using JSON (as you can in JavaScript), but it was not made for it. Anything that can represent """data""" and at least 2 nesting levels of arbitrary-length sequences can represent tabular data, which is basically every data format ever regardless of how awkward actually working with it may be.
kccqzy 2y ago
JSON is designed to represent JavaScript objects with literal notation. Guess what, an array of strings or an array of numbers or even an array of mixed strings and numbers is a commonly encountered format in JavaScript.
kazinator 2y ago
A format consisting of newline-terminated records, each containing comma-separated JSON strings would be superior to CSV. It could use backslash escapes to denote control characters and Unicode points. Everyone would agree exactly on what the format is, in contrast to the zoo of CSV variants. It wouldn't have pitfalls in it, like spaces that defeat quotes RFC CSV JSON strings a,"b c" "a", "b c" a, "b c" "a", " \" b c\"" oops; add an innocuous-looking space, and the quotes are now literal.
- deleted 2y ago
  [deleted]
  - kazinator 2y ago
    "Any JSON primitive" does add a few requirements not semantically comparable to CSV, like numbers that are numbers, and keywords true, false, none. When these syntaxes are parsed into objects, either the type info has to be retaind, or some kind of attribute tag, so they can be output back to the same form. > make it so any consumer can parse it by splitting on newline and then ... There is something like that called JSON-lines. It has a .org domain 'n' everything: https://jsonlines.org/ https://jsonlines.org/

You're missing my point: basically nothing spits out data in that format because it's not ergonomic to do so. JSON is designed to represent object hierarchies, not tabular data.

koolba 2y ago

JSON was designed to represent any data. There's plenty of systems that spit out data in exact that format because it's the natural way to represent tabular data using JSON serialization. And clearly if you're the one building the system you can choose to use it.

hajile 2y ago

CSV is lists of lists of fixed length. JSON is lists of lists of any length and groups of key/value pairs (basically lisp S-expressions with lots of unnecessary syntax). This makes it a superset of CSV's capabilities. JSON fundamentally IS made to represent tabular data, but it's made to represent key-value groups too. Why make it able to represent tabular data if that's not an intended use?

meepmorp 2y ago
> CSV is lists of lists of fixed length. I'd definitely put that in my list of falsehoods programmers believe about CSV files.
- timacles 2y ago
  CSV is a text file that might have commas in it
  - deleted 2y ago
    [deleted]
- hajile 2y ago
  It seems to be indicated by RCF-4180 which says > This header will contain names corresponding to the fields in the file and should contain the same number of fields as the records in the rest of the file But of course, CSV is the wild west and there's no guarantee that any two encoders will do the same thing (sometimes, there's not even a guarantee that the same encoder will do the same thing with two different inputs). [0] https://www.ietf.org/rfc/rfc4180.txt https://www.ietf.org/rfc/rfc4180.txt
  - HelloNurse 2y ago
    You should know that "should" isn't very binding. Headers should have as many rows as possible that contain data items for their column and data items in a row should have a header for the respective columns, but real CSV files should be assumed to have incomplete or variable length lines.
    - hajile 2y ago
      NOTHING is very binding about the CSV spec and that's the biggest problem with CSV.
- miningape 2y ago
  yeah if I had a cookie for every time I've had to deal with this I'd have maybe 10 cookies - it's not a lot but it's more than it should be.
freehorse 2y ago
The fact that json can represent a superset of tabular data structures that csv is specifically designed to represent can be rephrased into that csv is more specialised than json in representing tabular data. The fact that json can also represent tabular data does not mean it is a better or more efficient way to represent that data instead of a format like csv. In the same way, there are hierarchically structured datasets that can be represented by both json in hierarchical form and csv in tabular form by repeating certain variables, but if using csv would require repeating them too many times, it would be a bad idea to choose that instead of json. The fact that you can do sth does not always make it a good idea to do it. The question imo is about which way would be more natural, easy or efficient.
- hajile 2y ago
  It's hardly a bad idea to do a list of lists in JSON... The big advantage of JSON is that it's standardized and you can reuse the JSON infrastructure for more than just tabular data.
- Kinrany 2y ago
  > The fact that json can represent a superset of tabular data structures that csv is specifically designed to represent can be rephrased into that csv is more specialised than json in representing tabular data. The fact that json can also represent tabular data does not mean it is a better or more efficient way to represent that data instead of a format like csv. The reverse is true as well: being more specialized is a description of goals, not advantages.
deleted 2y ago
[deleted]
packetlost 2y ago
> JSON is lists of lists of any length and groups of key/value pairs The "top-level" structure of JSON is usually an object, but it can be a list. > JSON fundamentally IS made to represent tabular data No, it's really not. It's made to represent objects consisting of a few primitive types and exactly two aggregate types: lists and objects. It's a textual representation of the JavaScript data model and even has "Object" in the name. > Why make it able to represent tabular data if that's not an intended use? It's mostly a question of specialization and ergonomics, which was my original point. You can represent tabular data using JSON (as you can in JavaScript), but it was not made for it. Anything that can represent """data""" and at least 2 nesting levels of arbitrary-length sequences can represent tabular data, which is basically every data format ever regardless of how awkward actually working with it may be.

kccqzy 2y ago

JSON is designed to represent JavaScript objects with literal notation. Guess what, an array of strings or an array of numbers or even an array of mixed strings and numbers is a commonly encountered format in JavaScript.

kazinator 2y ago

A format consisting of newline-terminated records, each containing comma-separated JSON strings would be superior to CSV. It could use backslash escapes to denote control characters and Unicode points. Everyone would agree exactly on what the format is, in contrast to the zoo of CSV variants. It wouldn't have pitfalls in it, like spaces that defeat quotes RFC CSV JSON strings a,"b c" "a", "b c" a, "b c" "a", " \" b c\"" oops; add an innocuous-looking space, and the quotes are now literal.

deleted 2y ago
[deleted]
- kazinator 2y ago
  "Any JSON primitive" does add a few requirements not semantically comparable to CSV, like numbers that are numbers, and keywords true, false, none. When these syntaxes are parsed into objects, either the type info has to be retaind, or some kind of attribute tag, so they can be output back to the same form. > make it so any consumer can parse it by splitting on newline and then ... There is something like that called JSON-lines. It has a .org domain 'n' everything: https://jsonlines.org/ https://jsonlines.org/