Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A love letter to the CSV format

github.com

Post reply on HN
Print view View original

191–200 of 711 posts

Re: A love letter to the CSV format

#191

Post by macintux »

EGreg wrote: post #51
mjevans wrote: post #28

Earlier quoted context omitted.

The _entire_ point of a CSV file is that it's fully human readable and write-able. The characters you mention could be used in a custom delimiter variant of the format, but at that point it's back to a binary machine format.

Can't there be some magic sequence (like two unescaped newlines) to start a new record?

You’ll still find that sequence in data; it’ll just be rare enough that it won’t rear its ugly head until your solution has been in production for a while.

Re: A love letter to the CSV format

#192

Post by matthewmacleod »

otikik wrote: post #187
derriz wrote: post #166

Earlier quoted context omitted.

> It’s that libraries and tools to parse CSV tend to suck. Whereas JSON is the lingua franca of data. This isn't the case. An incredible amount of effort and ingenuity has gone into CSV parsing because of its ubiquity. Despite the lack of any sort of specification, it's easily the most widely supported data format in existence in terms of tools and language support.

Meanwhile, Excel exports to CSV as “semicolon separated values” depending on your OS locale

Albeit for fairly justifiable reasons

Re: A love letter to the CSV format

#193

Post by [deleted] »

thesuitonym wrote: post #149
criddell wrote: post #136

Earlier quoted context omitted.

> use something else You don't always get to pick the format in which data is provided to you.

True, but in that case I'm not the one choosing how to store it, until I ingest the data, and then I will store it in whatever format makes sense to me.

[deleted]

Re: A love letter to the CSV format

#194

Post by noitpmeder »

hajile wrote: post #163
rcbdev wrote: post #153

Earlier quoted context omitted.

Same for JSON though. What Python considers a valid JSON might not be that if you ask a Java library.

JSON has a clearly-defined standards: ISO/IEC 21778:2017, IETF RFC 7159, and ECMA-404. Additionally, Crockford has had a spec available on json.org since it's creation in 2001. Do you have any examples of Python, Java, or any of the other Tiobe top 40 languages breaking the JSON spec in their standard library? In contrast, for the few of those that have CSV libraries, how many of those libraries will simply fail to p…

It falls down under very large integers -- think large valid uint64_t values.

Re: A love letter to the CSV format

#195

Post by derriz »

hajile wrote: post #183
derriz wrote: post #166

Earlier quoted context omitted.

> It’s that libraries and tools to parse CSV tend to suck. Whereas JSON is the lingua franca of data. This isn't the case. An incredible amount of effort and ingenuity has gone into CSV parsing because of its ubiquity. Despite the lack of any sort of specification, it's easily the most widely supported data format in existence in terms of tools and language support.

Can you point me to a language with any significant number of users that does NOT have a JSON library? I went looking at some of the more niche languages like Prolog, COBOL, RPG, APL, Eiffel, Maple, MATLAB, tcl, and a few others. All of these and more had JSON libraries (most had one baked into the standard library). The exceptions I found (though I didn't look too far) were: Bash (use jq with it), J (an APL variant)…

I made no claim about JSON libraries. I contested the claim that "CSV libraries and tools suck". They do not.

Re: A love letter to the CSV format

#196

Post by munchler »

hajile wrote: post #65

The argument against JSON isn't very compelling. Adding a name to every field as they do in their strawman example isn't necessary. Compare this CSV field1,field2,fieldN "value (0,0)","value (0,1)","value (0,n)" "value (1,0)","value (1,1)","value (1,n)" "value (2,0)","value (2,1)","value (2,n)" To the directly-equivalent JSON [["field1","field2","fieldN"], ["value (0,0)","value (0,1)","value (0,n)"], ["value (1,0)","…

> the directly-equivalent JSON

    [["field1","field2","fieldN"],
     ["value (0,0)","value (0,1)","value (0,n)"],
     ["value (1,0)","value (1,1)","value (1,n)"],
     ["value (2,0)","value (2,1)","value (2,n)"]]
I think it's a big stretch to use that JSON for comparison. In practice, one is much more likely to see this:

    [
      {
        "field1": "value (0,0)",
        "field2": "value (0,1)",
        "fieldN": "value (0,n)"
      },
      {
        "field1": "value (1,0)",
        "field2": "value (1,1)",
        "fieldN": "value (1,n)"
      },
      {
        "field1": "value (2,0)",
        "field2": "value (2,1)",
        "fieldN": "value (2,n)"
      }
    ]

Re: A love letter to the CSV format

#199

Post by gghffguhvc »

lgas wrote: post #182
koolba wrote: post #131

Earlier quoted context omitted.

You can easily represent it as an array: [“foo”,”bar”,123] That’s as tabular as CSV but you now have optional types. You can even have lists of lists. Lists of objects. Lists of lists of objects…

Typing isn't optional in JSON, every value has a concrete type, always.

  [
   [“header1”,”header2”],
   [“1.1”, “”],
   [7.4, “2022-01-04”]
  ]
Post reply on HN