3 ms·

This is an example of a genre I like to describe as: programmer objects to a solution that meets everyone's requirements because it doesn't make them feel like

by _moof 5y ago

This is an example of a genre I like to describe as: programmer objects to a solution that meets everyone's requirements because it doesn't make them feel like a beautiful code-poet. I like elegance as much as anyone. And I think it's a good proxy for other important qualities. But don't prioritize it above building something that actually does the job. Be an engineer.

qayxc 5y ago
Ah yes, and then there's https://www.theverge.com/2020/8/6/21355674/human-genes-rename-microsoft-excel-misreading-dates https://www.theverge.com/2020/8/6/21355674/human-genes-renam... Not to mention the mess that is exchanging documents between different locales. It's all sunshine and roses until you get your CSVs from an office in a different country (which happens a lot in Europe). CSV gets the job done until it doesn't.
- brushfoot 5y ago
  That's not a problem inherent to CSV the format, though, any more than using Word to edit JSON means smart quotes are a problem with JSON. It's about knowing or not knowing the tools you're using. Unexpected behavior is a potential problem with any tool or format, certainly no less so with the kinds of solutions the article is proposing.
  - qayxc 5y ago
    But the behaviour isn't unexpected at all, e.g. the user wanted to store a number in column 3 and that's exactly what's the tool did. The behaviour is both expected and reproducible, the issue is that it's not communicated by the format. The problem arises from the fact that CSV doesn't contain any metadata so while the same tool reads and writes the same data, the results will be different because the format doesn't specify what a number look like. The formats proposed in the article don't have this problem because they specify both the type and the formatting of the file content so there's no confusion. That's the difference. JSON in particular simply cannot have this problem (though it's not a suggested solution): a number has a well-defined format and that's that. So do strings. This is not the case with CSV: Number,Also a number,A String 1.0,1e15,"Hello there!" "1,0",1e15,"Bienvenue á la maison!" The first row is what you'd expect from a customer in Ireland and the second row might be sent from someone in Switzerland. Both parties agreed to use comma-separated files for data exchange and quoted strings, yet importing the first row using a French locale would fail to parse the first number and same goes for the second row and an English locale. Neither row contains unexpected or malformed data from the respective user's POV. And that's the problem with CSV.
- p_j_w 5y ago
  >CSV gets the job done until it doesn't. Then you take it out of use where it doesn't get the job done.
- deleted 5y ago
  [deleted]

by _moof 5y ago

qayxc 5y ago

Ah yes, and then there's https://www.theverge.com/2020/8/6/21355674/human-genes-rename-microsoft-excel-misreading-dates https://www.theverge.com/2020/8/6/21355674/human-genes-renam... Not to mention the mess that is exchanging documents between different locales. It's all sunshine and roses until you get your CSVs from an office in a different country (which happens a lot in Europe). CSV gets the job done until it doesn't.

brushfoot 5y ago
That's not a problem inherent to CSV the format, though, any more than using Word to edit JSON means smart quotes are a problem with JSON. It's about knowing or not knowing the tools you're using. Unexpected behavior is a potential problem with any tool or format, certainly no less so with the kinds of solutions the article is proposing.
- qayxc 5y ago
  But the behaviour isn't unexpected at all, e.g. the user wanted to store a number in column 3 and that's exactly what's the tool did. The behaviour is both expected and reproducible, the issue is that it's not communicated by the format. The problem arises from the fact that CSV doesn't contain any metadata so while the same tool reads and writes the same data, the results will be different because the format doesn't specify what a number look like. The formats proposed in the article don't have this problem because they specify both the type and the formatting of the file content so there's no confusion. That's the difference. JSON in particular simply cannot have this problem (though it's not a suggested solution): a number has a well-defined format and that's that. So do strings. This is not the case with CSV: Number,Also a number,A String 1.0,1e15,"Hello there!" "1,0",1e15,"Bienvenue á la maison!" The first row is what you'd expect from a customer in Ireland and the second row might be sent from someone in Switzerland. Both parties agreed to use comma-separated files for data exchange and quoted strings, yet importing the first row using a French locale would fail to parse the first number and same goes for the second row and an English locale. Neither row contains unexpected or malformed data from the respective user's POV. And that's the problem with CSV.
p_j_w 5y ago
>CSV gets the job done until it doesn't. Then you take it out of use where it doesn't get the job done.
deleted 5y ago
[deleted]