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

I was wrong about spreadsheets (2017)

reifyworks.com

Post reply on HN
Print view View original

271–280 of 378 posts

Re: I was wrong about spreadsheets (2017)

#271

Post by Freak_NL »

davidpolberger wrote: post #184
Freak_NL wrote: post #162

Earlier quoted context omitted.

Excel goes one step further, and assumes that users in some locales (e.g., Dutch) want semicolons as separators in every CSV file you open in Excel . I don't care (I just use LibreOffice Calc, which accepts any delimited values file just fine, and just asks which separator to assume), but it means that when you develop an option for users to download some statistical data as comma-separated values file (which is easy…

You can specify what separator to use as the first line in the CSV file: sep=, My experience is that Excel 2007 and later will correctly parse the file and use the specified separator. However, other software, such as Google Sheets, will simply render the declaration as-is. Then there's the issue of what character encoding to use to encode the file, whether to include a byte-order-mark with UTF-8 to make Excel recogn…

That separator preamble seems Excel-specific though:

https://tools.ietf.org/html/rfc4180

If I'm going to mangle CSV into a non-standard form to conform to whatever Excel expects, I might as well go the extra mile and just provide an XLSX file.

That was my solution to a data-export function in an API (it switches on the HTTP Accept header). It now offers a choice of CSV (RFC 4180), ODS, and XLSX, and people can just pick XLSX if their Excel is using one of its broken locales.

It's not too hard to generate the XML for ODS (OpenOffice/LibreOffice etc.) and XLSX (Excel) from a bunch of tabular records once you've set up minimal empty template ODS/XLSX files to inject it in. It's certainly less work than explaining to Excel users that their software is broken and how to work around it.

That said, ODS was much easier to get working.

Re: I was wrong about spreadsheets (2017)

#273

Post by pulisse »

Difficulty recreating an Excel spreadsheet in a general-purpose programming language isn't evidence of the superiority of spreadsheets, it's just a consequence of the object/relational impedance mismatch. I strongly suspect that reimplementing OP's spreadsheet in MySQL wouldn't have presented any deep problems.

Re: I was wrong about spreadsheets (2017)

#274

Post by taneq »

ekianjo wrote: post #241
halfeatenpie wrote: post #26

I work in critical infrastructure planning. My organization builds software in R, Python, and other programming languages customized for these major organizations. So many critical infrastructures, billions of dollars in planning, and just systems are built out of Excel. It's amazing. You'd assume something that services millions of people a day would have some more sophisticated and customized solution, but you're w…

> I have deep respect for Excel. I do something around the same line as you describe (build better tools in R/Python for larger data problems) but I have a deep aversion to Excel. It's proprietary, has horrible standards (it does not support native UTF8 csv files for example), and is stuck in the 80's in terms of paradigm. And this is precisely the tool that prevents people from doing things more efficiently because…

Think of all the open, modern, nicely standards compliant tools that you use. Now think of the fact that Excel lets people solve their problems more easily than all the things you like.

I'm not saying it's good, but it's better than everything else (for the people who use it.)

Re: I was wrong about spreadsheets (2017)

#275

Post by ubermonkey »

piokoch wrote: post #99
whyenot wrote: post #48

Just don't try to use dates before January 1, 1900 (or 1904 on Mac). You can work with dates in Excel 1,000 years in the future, but if you try to do that for dates from the 1800s it will completely screw them up. I don't understand why this problem still exists today. If you work in a museum, or anywhere else where you deal with old dates, you have to constantly be on the lookout for this "gotcha."

This is not directly related to issues you see, but might shed some light: https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev... (plus this is one of the funnies Joel Spolsky's text and an amazing dive into computers history).

I've read that piece before, but it's always worth reading again.

Re: I was wrong about spreadsheets (2017)

#276

Post by mkl »

mirimir wrote: post #10

I love spreadsheets. When I'm working out a method for analyzing some dataset, I just hack it out in Calc. Or if it gets too big, Excel. Once I've blocked it out, I move to MySQL. But I can do any database operation in Excel, or even Calc. Maybe not efficiently, but well enough. But I've also learned that basic Linux tools (grep, sed, tr, awk, sort, uniq, etc) are far more efficient for cleaning and preparing data fo…

What Gnumeric charts are you referring to? The ones I could find [1] seem pretty standard.

[1] https://help.gnome.org/users/gnumeric/stable/sect-graphs-ove...

Re: I was wrong about spreadsheets (2017)

#277

Post by giardini »

davedx wrote: post #142
thom wrote: post #138

I always like these threads where programmers talk about tools like Excel and say they’re fine for small stuff but grow out of hand, as if 90% of codebases built by professional programmers aren’t exactly the same.

But professional programmers (emphasis on professional) are well aware of how codebases can grow out of hand and employ entire categories of theories, strategies and tools to keep their software maintainable, even when under delivery/time pressure. Excel doesn't really have much in this category of theories and tools.

You really should look at some of the links I provide above to Jocelyn Ireson-Paine's work.

Re: I was wrong about spreadsheets (2017)

#278

Post by odonnellryan »

halfeatenpie wrote: post #26

I work in critical infrastructure planning. My organization builds software in R, Python, and other programming languages customized for these major organizations. So many critical infrastructures, billions of dollars in planning, and just systems are built out of Excel. It's amazing. You'd assume something that services millions of people a day would have some more sophisticated and customized solution, but you're w…

Excel is good, but the problem is data storage. I always wanted to try and solve that problem, but it is very hard.

I do similar work but a different industry. My solution has been also to have Excel downloads, which work really well, but there are drawbacks.

Re: I was wrong about spreadsheets (2017)

#280

Post by module0000 »

If spreadsheets work for your use-case or industry, then by all means keep using them. Occasionally, I'll use one myself for some business purpose. However...the problem with spreadsheets is that people routinely use them for the wrong reasons. Those wrong reasons are the cause of the spreadsheet hate. It's not spreadsheets themselves that cause this, it's people with limited knowledge and limited ambition to learn how to use the correct tool for a task.

The saying "when all you have is a hammer, everything looks like a nail" applies.

Often, someone using spreadsheets will suspect that their task may be better accomplished in some manner of programming. This leads them to try to do it. If they are in this situation, chances are, they are not a professional programmer. They are going to have a poor experience, and likely fail. This is due to sub-par or non-existent software engineering skills, and not due to spreadsheets being the correct tool for every task.

Post reply on HN