3 ms·

CSV is a mess. A while back we switched to exporting XLSX using the xlsx module https://www.npmjs.com/package/xlsx https://www.npmjs.com/package/xlsx

deleted 9y ago
[deleted]
ng12 9y ago
How can CSV be a mess? The implementation is in the name. Excel is a mess.
- TAForObvReasons 9y ago
  The mess is in the "V". RFC4180 leaves value interpretation to the application. It doesn't tell you, for example, when a string like 12345 should be interpreted as a number. So we end up sending numbers and dates and other meaningful values into the ether, hoping that the end application understands what you meant to convey. XLSX has a cell type for IEEE754 doubles, so there is no such ambiguity. It also has a special date type!
  - paulddraper 9y ago
    Protocol buffers don't tell you what the data types are either in the actual message. It's a trade-off, but I prefer to communicate format out of band, not in every single message.
    - traviscj 9y ago
      My take: include a schema when you can and there's a justification and it's practical. IMO even JSON is a (very limited, "name only, no type") type of schema. If it becomes impractical for something you're doing, stop and switch to something less redundant.
  - ng12 9y ago
    That's still not a failing of CSV. If knowing whether a V is an IEEE754 double is critical to your application you shouldn't be using CSV. You wouldn't say nails are a mess because sometimes you need screws.
    - TAForObvReasons 9y ago
      Knowing whether a value is a number or text or date is critical to myriads of application, and CSV specs give no guidance on how to interpret the actual values as numbers or text or dates. You don't have control over both endpoints in most cases, especially when you accept files from clients. Furthermore, they mix presentation and values (is `1.23%` a string or a number? What is the number?) XLSX separates the value from presentation and gives every value a clear type. If a value is a number, there's a concrete numeric value that is stored separately from the number format. That way there is no guesswork involved, you can figure out exactly what the value is with zero magic.
      - ng12 9y ago
        You're missing the point. You're just listing use cases for which CSV does not fit. CVS's strengths are simplicity and ubiquity. It has existed long before Excel and will probably outlive it. You can't say it's a mess because it doesn't help you parse "1.23%" reliably and constantly -- that's not CSV's job. To try another analogy: you can't say square pegs are poorly designed because you have round holes.
        deleted 9y ago
        [deleted]
        chronial 9y ago
        Then what exactly is CSV good for? I don't know any usecase where I need to programmatically exchange values without meaning in an open format.
        ng12 9y ago
  - deleted 9y ago
    [deleted]
kauegimenes 9y ago
You can use jsonexport with rowDelimiter: '\t' for a xls compatible output.

deleted 9y ago

[deleted]

ng12 9y ago

How can CSV be a mess? The implementation is in the name. Excel is a mess.

TAForObvReasons 9y ago
The mess is in the "V". RFC4180 leaves value interpretation to the application. It doesn't tell you, for example, when a string like 12345 should be interpreted as a number. So we end up sending numbers and dates and other meaningful values into the ether, hoping that the end application understands what you meant to convey. XLSX has a cell type for IEEE754 doubles, so there is no such ambiguity. It also has a special date type!
- paulddraper 9y ago
  Protocol buffers don't tell you what the data types are either in the actual message. It's a trade-off, but I prefer to communicate format out of band, not in every single message.
  - traviscj 9y ago
    My take: include a schema when you can and there's a justification and it's practical. IMO even JSON is a (very limited, "name only, no type") type of schema. If it becomes impractical for something you're doing, stop and switch to something less redundant.
- ng12 9y ago
  That's still not a failing of CSV. If knowing whether a V is an IEEE754 double is critical to your application you shouldn't be using CSV. You wouldn't say nails are a mess because sometimes you need screws.
  - TAForObvReasons 9y ago
    Knowing whether a value is a number or text or date is critical to myriads of application, and CSV specs give no guidance on how to interpret the actual values as numbers or text or dates. You don't have control over both endpoints in most cases, especially when you accept files from clients. Furthermore, they mix presentation and values (is `1.23%` a string or a number? What is the number?) XLSX separates the value from presentation and gives every value a clear type. If a value is a number, there's a concrete numeric value that is stored separately from the number format. That way there is no guesswork involved, you can figure out exactly what the value is with zero magic.
    - ng12 9y ago
      You're missing the point. You're just listing use cases for which CSV does not fit. CVS's strengths are simplicity and ubiquity. It has existed long before Excel and will probably outlive it. You can't say it's a mess because it doesn't help you parse "1.23%" reliably and constantly -- that's not CSV's job. To try another analogy: you can't say square pegs are poorly designed because you have round holes.
      - deleted 9y ago
        [deleted]
      - chronial 9y ago
        Then what exactly is CSV good for? I don't know any usecase where I need to programmatically exchange values without meaning in an open format.
        ng12 9y ago
- deleted 9y ago
  [deleted]

kauegimenes 9y ago

You can use jsonexport with rowDelimiter: '\t' for a xls compatible output.