Hacker News Reader

Comment by sp4ke | Hacker News Reader

Sorry but this would only keep the proprietary file format madness that is Excel. I would prefer to share the data in JSON and let the user decide what to do with it ...

View on HN

Unless your end user is a developer, that's a distinctly unfriendly way to treat your users. Did you read the article? The point is that non-developer end users will never use CSV in anything but a spreadsheet, and Excel is the most prominent of those.

To give it to them in JSON is, well, just useless.

A lovely sentiment, but one made in total denial of reality.

Handing your average user a JSON file doesn't "let them decide", it means you've decided that their needs are less important than your holy war. That's fine, and your choice to make as a developer (unless they're paying you), but don't pretend it's in the user's best interest.

The premise of the article is that the user will want to manipulate the data in Excel, so developers should provide an Excel export instead of / as well as CSV. In this case, JSON is much, much worse than CSV.

The majority of users have no idea what JSON is or how to even open it. So "decide what to do with it" will equate to trash it and find another website.

I'm not current in MS World, but I wonder if Excel handles this now, or will soon, given their recent, progressive bent.

That doesn't solve the lossless encoding of doubles problem.

Lossless encoding of doubles is a long solved problem. Use hexadecimal floating point format (%a with printf in C99, inherited by most high-level languages that sit on top of C). The problem is platforms that still don't support C99.

It is absolutely a solved problem, but printing hex floats into JSON or a CSV isn't going to be great when you need to re-import the data somewhere.

I was wondering why he said that CSV was not capable of supporting full precision for doubles. Are you saying that the problem is not with CSV per se, but instead the C libc printf function? I'd have thought that modern standard libraries would do this right with the usual decimal %f and a large enough precision: http://pubs.opengroup.org/onlinepubs/009695399/functions/pri...

The trouble is that (a) the standard recommends but does not require that all binary-to-decimal and decimal-to-binary conversions be correctly rounded and (b) even if it did require correctly-rounded conversions, the precision needs to be absolutely enormous to guarantee that every double is exactly representable in the chosen format (which makes it wildly wasteful), otherwise you'd get different results depending on the rounding mode in effect at the time of conversion back to double.

Reply on news.ycombinator.com