DSVs are pretty bad, CSVs are kinda OK (just don’t ever open one in Excel)
Directly opening CSV files in Excel does mot work for me, too, importing a CSV file however works devently well for me.
CSVs Are Kinda Bad. DSVs Are Kinda Good
21–30 of 133 posts
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#22The article talks about reading and parsing CSV data of unknown variants, but then skips to the solution being using a different format altogether. But you can only switch to a different format if you are producing data, not if you are reading it! And if you are in control of producing data, just produce strict RFC 4180-compliant CSV data and everybody will be able to read it just fine. There is no need to make your…
It’s the classic ‘self driving is easy when we modify the world to be what we want’ type solution.
"Politics is easy, the problem is we aren't working together!"
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#23If you strip the exchangeability from an exchange format, it is useless.
DSVs didn't work with either Google Sheets, nor vim and neither Python – I assume this is the exhaustive list of software the author would have needed support from. The question, then: If no software understands the format, what's the point?
> I first learned about these ASCII delimiters while working with .fec [Federal Election Commission] files.
And then the author instantly chose a different delimiter. Two parties and already two standards. That should have been the final red flag for this proposal.
--- Aside: CSVs have so many problems wit their data format that you have to always verify them anyway.
Germans write 5.000,24€ where an American would write $5,000.24. Date strings. URL-encoded strings. Numbers as strings. Floating numbers.
Solving the delimiter problem accomplishes nothing.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#24The article talks about reading and parsing CSV data of unknown variants, but then skips to the solution being using a different format altogether. But you can only switch to a different format if you are producing data, not if you are reading it! And if you are in control of producing data, just produce strict RFC 4180-compliant CSV data and everybody will be able to read it just fine. There is no need to make your…
[flagged]
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#25This keeps coming up as new people discover what CSVs are. An ancient TEXT data exchange format. The lowest vaguely common denominator. A style of format with flavors software long out of support contract are happy to export data in. The intent of the format is to be human readable and editable. Sure, Tab characters can be used instead of commas. (TSV files) Yes that's that "" to escape a quote rule. Oh and quoted va…
CSV isn't a common denominator of anything. Everything is communicated out of band. Nobody understands your CSV files.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#26CSV is kinda great .. but it does help to have nice tools to wrangle it, such as the famous xsv by burnt-sushi.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#27The article talks about reading and parsing CSV data of unknown variants, but then skips to the solution being using a different format altogether. But you can only switch to a different format if you are producing data, not if you are reading it! And if you are in control of producing data, just produce strict RFC 4180-compliant CSV data and everybody will be able to read it just fine. There is no need to make your…
[flagged]
I can just not use Excel :-)
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#28Earlier quoted context omitted.
> even programmers often don't know how to enter raw flow control characters on their systems. Yes, but that is because those characters are not meant to be entered directly. DSV values should either be created by a dedicated DSV editor or they should be constructed by a software library. You would rather use a paint program to create an image instead of writing the image's bytes in a text editor.
Aka a completely different use case than CSV.
> Aka a completely different use case than CSV.
How many CSVs are generated, edited, or viewed by Notepad.exe and how many by Excel (or Google Sheets)?
I would posit the vast majority of CSVs are generated through some kind of program where you go to File > Export or File > Save As…. In which case doing selecting a drop down with the option for File Format to be TSV or DSV (with the corresponding file extension) would solve a lot of problems. (Or at least if CSVs from Excel were RFC 4810 compliant by default.)
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#29The article talks about reading and parsing CSV data of unknown variants, but then skips to the solution being using a different format altogether. But you can only switch to a different format if you are producing data, not if you are reading it! And if you are in control of producing data, just produce strict RFC 4180-compliant CSV data and everybody will be able to read it just fine. There is no need to make your…
[flagged]
Don't use broken tools. The key phrase is "in control of producing data". If you're forced to use Excel, then it's not really you in control, is it?
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#30The only real benefit of CSV (other than that it is widely supported) is that it is easy for humans to read and write. The approach in this article solves the quoting problem, but also removes that benefit. If you have the power to move from CSV, surely JSON would be better if you need to keep the human readable/writable feature. And if you don't need it, there are other more featureful binary formats out there like…
JSON is often good, but it also has potentially a lot of overhead, depending on how sparse the data is. For sparse data, it might be better. But for not sparse data, it will have the overhead of mentioning attribute names over and over again. Of course you could also have arrays in JSON, not writing attribute names over and over, but then you are basically back to a CSV inside the JSON file ...
>Of course you could also have arrays in JSON, not writing attribute names over and over, but then you are basically back to a CSV inside the JSON file ...
You're confusing the concept of tabular data with the file format. If the most natural way to represent tabular data is through a 2D array, then so be it. The vast majority of people aren't complaining about the fact that they have to hardcode the meaning of "the last name is written into the fifth column", they are cursing that the fifth column has suddenly shifted into the sixth column, because the first name contained a comma.