41–50 of 355 posts
I literally don't get why JSON is bad: [{row1}, {row2}, {row3}] The fact that it can do more is in no way a negative. Can even make a limited JSON parser with reduced capabilities. And with JSON can do more definitions like header names vs column names vs just arrays of arrays.
And since it doesn’t require one record per line it can be a hassle to read without having to parse it.
It’s really nice to be able to do “head -n 5”
I literally don't get why JSON is bad: [{row1}, {row2}, {row3}] The fact that it can do more is in no way a negative. Can even make a limited JSON parser with reduced capabilities. And with JSON can do more definitions like header names vs column names vs just arrays of arrays.
[{"col1":"val1", "col1":"val2"}]
> No escaping. If you want to put \u001F or \u001E in your data – tough you > can’t. Use a different format. > It would be reasonably compact, efficient to parse and easy to manually edit > (Notepad++ shows the unit separator as a ‘US’ symbol). Is it me or it won't be human readable because of the lack of new lines?
I rarely want to see tabular data in a human-readable format. It is always the most tedious way to approach it. My go-to is Excel/LibreOffice Calc. This approach is at least tolerable to edit in a text editor, while something like the OpenDocument Spreadsheet format or the Excel format is impenetrable.
I think it’s a think where having the option for the .1% of times when you need it keeps me using it.
I literally don't get why JSON is bad: [{row1}, {row2}, {row3}] The fact that it can do more is in no way a negative. Can even make a limited JSON parser with reduced capabilities. And with JSON can do more definitions like header names vs column names vs just arrays of arrays.
If you can do anything, it becomes hard to do the right thing. If you can only do the right thing, it becomes trivial to decide.
I literally don't get why JSON is bad: [{row1}, {row2}, {row3}] The fact that it can do more is in no way a negative. Can even make a limited JSON parser with reduced capabilities. And with JSON can do more definitions like header names vs column names vs just arrays of arrays.
I could see a specialized form of JSON using jagged arrays
{"Header": ["Name", "Street Address", "City"]
"Body": [
["Alice", "123 Fake St", "Faketon"],
["Bob", "987 Any Pl", "Anytown"],
]}
if you are ok with a binary format there is apache parquet or apache feather or 'jay' ( https://datatable.readthedocs.io/en/latest/api/frame/to_jay.... ).
No doubt binary formats like Parquet are the way to go for high performance with multi-GB datasets. Seems like total overkill if you have a few hundred or thousand rows of data though. Being able to create/edit/view stuff in a text editor and easily version it is very useful.
And in terms of versioning, I have seen people commit diffs of csvs before, and they're equally unreadable.
CSV is a plain text format, but that basically buys you nothing. As long as you're going to be loading it into excel or whatever anyway, might as well just pick a good binary format like parquet.
Earlier quoted context omitted.
it will also be at least 2x bigger on disk for no reason.
Your data must be very sparse or include a lot of escape chars for that. I've seen a lot of CSV where everything is quoted, meaning that the cell separator is effectively "," which is only one character less than and still beats the pants off of JSON or XML. imho, it would be a good compromise, in that there's already partial tooling and GUI support.
It’s also harder to read.
If it's tabular, I want schema for the columns. Is this column a 'number' or a string? Even better, is there a max length or precision known? Can the cell be null and how is that represented? How are dates formatted? Are they UTC/specific TZ, etc. Most of my complaints about CSV relate to trying to determine the types used to parse or import as, not how commas are escaped. Excel, for example, actually warns you about…
I literally don't get why JSON is bad: [{row1}, {row2}, {row3}] The fact that it can do more is in no way a negative. Can even make a limited JSON parser with reduced capabilities. And with JSON can do more definitions like header names vs column names vs just arrays of arrays.
Doesn't have a great int64 number story, no native dates / date-times. If you want named tuples, then the names need to go everywhere, otherwise it's a serialization mechanism on top of JSON.
I think it’s because csv is good enough. All the standards I’ve seen haven’t been worth the effort to implement. So since csv, with all its flaws, is good enough it crowds out other open standards. People complain about it, but it’s not really much of a challenge to use csv. I’d also prefer it over the crap (rdf, xml, even schemad json) proposed by people who value more structure. It’s easier for me to just make clea…
https://www.rfc-archive.org/getrfc.php?rfc=4180
If you don't, then split each line on ",". Problem solved.
If you find tab delimited easier to read (as I do), then check out the IANA spec for TSV files:
https://www.iana.org/assignments/media-types/text/tab-separa...
It's easier to parse than CSV. Unfortunately, you have to decide how to handle newlines and tabs yourself (probably as \n, \t, with \\ for backslashes).