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

171–180 of 378 posts

Re: I was wrong about spreadsheets (2017)

#171

Post by Blackstone4 »

Having worked a decent amount in Excel, here are my key issues:

- VBA Macros and Sheets are two distinct paradigms. Within an Excel file, it is not always clear how the two interact and requires meaningful digging.

- Once a numerical model has been calculated in a sheet, it is difficult to scale it. Yes, it is possible to copy sheets but if you make a change or want to do something 100's+ of times, it's a pain.

- Data integrity is a problem. Opps I pressed the wrong key and I deleted some data. Oh shit, I don't have Git to compare what was changed.

PS article dated 2017

Re: I was wrong about spreadsheets (2017)

#172

Post by TuringTest »

ChrisCinelli wrote: post #107
viraptor wrote: post #21

My issue with spreadsheets is that they could be improved a lot with minimal changes, not nobody seems to do it in popular office packages. Making them more database-like and making table data first-class (at least you can make named tables in excel on windows) could be used to push people a bit more towards organised data, without changing how anything works. Half of the mess that makes excel hell comes from the fac…

I agree. Both https://airtable.com/ and https://www.smartsheet.com/ in my option add some value on top. Unfortunately they are not omnipresent as Google Sheets and Excel. > Half of the mess that makes excel hell comes from the fact it's too easy to put two tables of data + some random constants on a single sheet and refer to them by H3. That is a feature. If you can keep in a screen all the data you need, you reduce…

> it does not seem a lot more different that starting with a prototype

People underestimate this point. Spreadsheets are one of the best possible approaches for prototyping data-driven applications, thanks to its dual data/code nature and the ease to build and extend data types (just add more columns to a table); it's like building the application inside a debugger.

Non-developers don't have anything else that resembles a debugger, anywhere in the common approaches of software for end-users in industry.

Combine this with spreadsheet applications working as integrated environments -a single tool that handles all the computing needs of a project, without having to build a toolchain-, and it's no wonder than it's the preferred method for non-programmers to build custom automation workflows when their needs aren't supported by any specific software.

Re: I was wrong about spreadsheets (2017)

#173

Post by Sahhaese »

qwerty456127 wrote: post #154

I can hardly imagine what is that which is easy in Excel but hard in Python with Pandas and SqliteiteAlchemy/Pytable/whatever and matplotlib. What really annoys me in Excel is they won't replace the fossil VBA with Python, F# or a new language designed from scratch right for this. The VBA environment feels fun to touch to have the feeling of time-travelling back to the years of your childhood but it feels quite clums…

You lack imagination.

I'm a professional software developer and I open excel every day.

Let's say someone emails me a list of figures and I want to quickly add them up?

Sure, I could write an incantation in awk but I can't then see if it's wrong because maybe on one row they 'accidentally' put an extra blank column in before the number by marking it with a letter, or there being an extra tab or whatever might cause that.

It's far quicker and less error prone to pop open excel, paste it in and then sum the column, and most importantly there is clear visual feedback if that doesn't work. In awk or a programming environment you'd just either get an incorrect figure and never know it was incorrect, or you'd get an error (e.g. trying to add a letter and number) and then have to debug what should have been an instant thing.

Excel shines for doing one-shot data processing.

Re: I was wrong about spreadsheets (2017)

#174

Post by Grumbledour »

Freak_NL wrote: post #162
franga2000 wrote: post #158

Earlier quoted context omitted.

While I haven't encountered localized names, localized formats make Excel an absolute pain for me. My language uses the "European" number format of a comma for decimals and periods for thousands separators. Excel tries to adjust to that by using semicolons for argument separators (i.e. ADD(1.5, 3.5) -> ADD(1,5; 3,5)). The problem is that their locale detection is wildly inconsistent and there isn't a good way to over…

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…

And that's not even the worst. You can teach people the few buttons necessary to read in the text, but once they save it again, the file is changed! Now you have a different separator and chances are good, excel also mangled date columns, removed leading zeros from numbers and switched out decimal separators! So you may not be able to further process the file. And its also sad, because if they just made some of these changes optional, excel would be a good tool to quickly work on an csv file and pass it on. But as is, I am always hesitant to work with csv in excel, because it mostly breaks and becomes unusable for further processing.

Re: I was wrong about spreadsheets (2017)

#175

Post by rtrr_eter »

mdorazio wrote: post #7

The sheer number of everyday business use cases that can be solved quickly and efficiently with spreadsheets is pretty astounding. Of course, there comes a point when heavily-used spreadsheets become intricate behemoths on which core business functions are run, and then things can get bad in a hurry. The challenge many programmers face is thinking that every business problem is best solved with code, when in reality…

I guess it more applies to unix shell.

Re: I was wrong about spreadsheets (2017)

#176

Post by ezequiel-garzon »

coldtea wrote: post #167
Xelbair wrote: post #127

Earlier quoted context omitted.

I just hate one single thing about Excel - all function names are localized - and in case of my native language - they are horrible and inconsistent.

Don't use the localized version of Excel in general. Problem solved.

In a corporate environment you normally don’t get to choose that.

Re: I was wrong about spreadsheets (2017)

#177

Post by TuringTest »

LeonB wrote: post #106
epistasis wrote: post #37

Earlier quoted context omitted.

I'd recommend watching this YouTube video; it's only one person's take on the right way to use Excel, but Excel has many ways to handle these issues: https://m.youtube.com/watch?v=0nbkaYsR94c

The link is to "You Suck at Excel" by Joel Spolsky, which is an excellent tutorial. I sincerely wish it had a different name, though! I would love to send this video to some of my business colleagues inside a large enterprise. They need this information and they would enjou everything about this video. However, it would not be acceptable to send them a video entitled "You Suck at Excel." If it had a more enterprise-f…

You can embed it in a more professional page, and hope that no one will notice the title at the overlay ;-)

Re: I was wrong about spreadsheets (2017)

#178

Post by baq »

coldtea wrote: post #167
Xelbair wrote: post #127

Earlier quoted context omitted.

I just hate one single thing about Excel - all function names are localized - and in case of my native language - they are horrible and inconsistent.

Don't use the localized version of Excel in general. Problem solved.

tell that to enterprise IT.

Re: I was wrong about spreadsheets (2017)

#179

Post by Mvandenbergh »

It's interesting how often people's response to the manifest problems caused by people using Excel in unfortunate ways is to either suggest tools with much steeper learning curves or to suggest additional Excel features. 99% of these problems can be solved by proper training and standards appropriate to the problem and context at hand.

For instance: Always separate and label inputs, calculations, and outputs.

Document where source data has come from, where one cell has had an ad-hoc adjustment made, what formulas do.

Use some type of version control and don't keep loads of concurrent versions around floating on email and local hard drives.

If the spreadsheet loads data from external sources, try and make that load automatic and live to prevent staleness.

Consistent formatting rules.

If data is tabular, put it in an Excel table. If data is tabular and we are always doing the same queries on it, and it is large then we move it to a database but that rarely happens.

Make it clear who owns spreadsheets and is responsible for keeping either/or data & functions/formulas to work.

Do all of this first, only then start thinking of replacing Excel with something else.

Re: I was wrong about spreadsheets (2017)

#180

Post by osullivj »

simonh wrote: post #122

I used to work at a bank that built a huge integrated application development and deployment stack on Python. One aspect of it was a custom library implementing a Directed Acyclic Graph, basically a way to ink up properties so that when the results of one property changed, any dependent properties on the DAG would automatically recalculate. This was explicitly implemented so that we could directly translate the logic…

Sounds like Athena at JP, or Quartz at BAML. Those off graph errors drove me nuts.
Post reply on HN