Easy to write, hard to read. Perfect illustration of an emergent case of Postel's Law.
So You Want to Write Your Own CSV code
11–20 of 127 posts
Re: So You Want to Write Your Own CSV code
#12Earlier quoted context omitted.
Importing into excel is probably a big reason.
If Excel compatibility is the goal, one should use libraries that read and produce Excel files. CSV is bullshit, it's not good for anything except scenarios where you control both the export process, and the parser (so you know what delimiter is used and so on).
The same could be said about exporting to JSON. (the JSON code on some of the big APIs does not parse intelligently and I have to spend a lot of time fixing it.)
Re: So You Want to Write Your Own CSV code
#13Why are people using CSV when better (and less fuzzily defined) solutions exist, such as JSON?
In addition to aforementioned import/export data interop with MS Excel, there are tons of legacy systems (mainframes, etc) that import/export csv but not XML or JSON. The csv format is everywhere and will continue to be with us for decades. People will always look for a quality library (in whatever new programming language) that handles all tricky edge cases.
A few months ago, I was trying to get some bulk data into ebay's proprietary TurboLister[1] program. Guess what, it can import csv but not JSON.
SQLite[2] can import csv but not JSON.
Google's terabyte ngram dataset[3] is csv (tsv) instead of JSON. I'm glad it's not JSON because it would have required extra disk space.
... plus tons of other real-world csv examples out in the wild.
Unfortunately, the csv format is very easy for programs to write but it's very difficult for programs to properly read because of the tricky parsing.
[1] http://pages.ebay.com/sellerinformation/sellingresources/tur...
[2] http://www.sqlite.org/cvstrac/wiki?p=ImportingFiles
[3] http://storage.googleapis.com/books/ngrams/books/datasetsv2....
Re: So You Want to Write Your Own CSV code
#14Earlier quoted context omitted.
If Excel compatibility is the goal, one should use libraries that read and produce Excel files. CSV is bullshit, it's not good for anything except scenarios where you control both the export process, and the parser (so you know what delimiter is used and so on).
The same could be said about exporting to JSON. (the JSON code on some of the big APIs does not parse intelligently and I have to spend a lot of time fixing it.)
[deleted]
Re: So You Want to Write Your Own CSV code
#15I think this example is relevant to many seemingly trivial problems. Where the task seems simple, but once you think about the details a bit more it becomes complex.
I was trying to get Perl tar libraries working, when my colleague asked why I don't just use backticks to do it in the shell. Basically because I don't know that much about tar. I can use it to untar file, or create a new archive. Someone else who has written a library probably has taken the time to read through the whole manual and make it work nicely. They know the errors and warnings, and have abstracted that to a sensible level hopefully. They have thought about these things, so hopefully I won't have to.
Re: So You Want to Write Your Own CSV code
#16This article makes it much more complicated than it needs to be. It tries to be all things to all people. In practice you're going to have to sacrifice some functionality for the sake of usability and your own sanity.
When I add a CSV import feature to a project I'm working on, I tell people "this works with MS Excel flavor of CSV." This covers most, if not all, real world cases because in my world the people who want to import data are non-programmer types who all use Excel.
I'll often include the basic rules in the screen that accepts the import. If I ever had to accept data from something that was _not_ Excel I'd probably include a combo box on the web form that lets you pick the dialect. So far I haven't had to do that.
The only thing I might not be totally covering is how Excel handles newlines, but in practice I've never had to deal with that.
Re: So You Want to Write Your Own CSV code
#17Re: So You Want to Write Your Own CSV code
#18This article makes it much more complicated than it needs to be. It tries to be all things to all people. In practice you're going to have to sacrifice some functionality for the sake of usability and your own sanity. When I add a CSV import feature to a project I'm working on, I tell people "this works with MS Excel flavor of CSV." This covers most, if not all, real world cases because in my world the people who wan…
Makes total sense to focus on the format the user actually uses. Still...why don't you use a library?
Re: So You Want to Write Your Own CSV code
#19This article makes it much more complicated than it needs to be. It tries to be all things to all people. In practice you're going to have to sacrifice some functionality for the sake of usability and your own sanity. When I add a CSV import feature to a project I'm working on, I tell people "this works with MS Excel flavor of CSV." This covers most, if not all, real world cases because in my world the people who wan…
Does it work with Hungarian Ms Excel? It uses semicolons as delimiters.
Re: So You Want to Write Your Own CSV code
#20Why are people using CSV when better (and less fuzzily defined) solutions exist, such as JSON?
If your data are rectangular and you care about performance, CSV is better than JSON just because it avoids repetitive key names everywhere. Then again, if your data are rectangular and you really care about performance, you would not use any of these (you might use HDF5, which has support in many programming languages and will destroy the others in terms of speed).