It is still the most common interchange format for tabular data. Tabular data is too verbose/unreadable when represented in standard JSON. Databases and Data Science are also on the rise; .csv continues to ride this wave.
In other words, people thinking they can just join(",") keeps them from reaching for an actual serializer (JSON, XML, etc), and if they realized they already have to bring in a CSV library anyways, they might consider using another format. Comedy gold, huh? Though I'm only half-joking, I've done it before and we've all consumed "CSV" from people who had the some presumption. :)
CSV generation and parsing is inconsistent based on tooling (see inevitable space/comma/quote problems, for example), while JSON has a strict enough spec that you can unambiguously use it in the same way for CSV-like data as long as nobody needs to literally edit it directly in Excel.
CSV forces struct-of-arrays and forces each row to have the same structure. Those are sometimes useful constraints. Also, you can obtain it from (legacy app) and open it in excel.
Text tools have intermittent support for those which would destroy the one big advantage of CSV.
Once you're using a binary format, you might as well use something like parquet or hdf5 (or ASN.1 I suppose) that give you other goodies in addition to airtight data/organization separation.
Wait, seriously? Interesting. Can you link me to something that demonstrates that was intended rather than a quirk of the simple format?
I always thought it was chosen since it was a seemingly sensible delimiter at first glance and then you only realize it's less useful well after you see others using your spreadsheet app for storing complex strings.
> Can you link me to something that demonstrates that was intended rather than a quirk of the simple format?
It’s hard to find references of the intentions of the creators for a format this old, which evolved over decades of different software having similar input formats, starting in 1972. Most of these early descriptions accept both spaces and commas as separators, hinting at a manual input process.
The closest I can find is a 1983 reference¹ which indicated that the format “…contains no other control characters except the end-of-file character…”, which I take to mean that the format is easy to handle and process with other text-handling tools, but still, no definite reference of direct intent.
It does seem like it was made to be easy to visually parse but it still feels like the delimiter choice has been something of historical baggage (to the point where just changing the delimiter itself, such as TSV, makes it easier to parse).
I wondered about this and apparently it dates to 1972: https://blog.sqlizer.io/posts/csv-history/ - in which case it may have been used for EBCDIC conversion! It looks like it pre-dates the spreadsheet (early 80s, Mitch Kapor/Lotus) by a long way.
I might be missing something, but isn't that somewhat obvious?
Sometime between 8-12 I 'invented' csv when I need to save data for some simple game I built. It seems like the most obvious solution to come up with: store data in a text file, separate the fields with a comma (or other character) and the 'entries' with a newline.
Note: The spreadsheet program comes from 1979 and VisiCalc, which was so enormously popular that many people bought Apple II computers just to run VisiCalc. Lotus 1-2-3 was written a few years later as a VisiCalc clone which took advantage of the larger screen and memory of the IBM PC.
I suspect that a lot of the popularity is piggy-backing on the popularity of JavaScript.
But what the heck is .CSV doing on an incline?!