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

261–270 of 378 posts

Re: I was wrong about spreadsheets (2017)

#261

Post by ubermonkey »

elalaouifaris wrote: post #76

I worked with excel for some years early in my career. I did not know how to program back then beyond if else and for loops. We used it for budget estimation at multi million / up to 100 m. I have seen other uses in Corp world in many departments. IMHO I think it’s good for specific use cases. But it is routinely abused beyond that. The key shortcomings for excel uses by non-programmers for key business applications:…

Data frames are going to be huge. This year I started using them for a personal project -- python, jupyter notebooks, and pandas -- and was astonished at how easy it was to get running, and how powerful.

I feel like lots of number people, once exposed to it, will realize that there's a place to go after Excel that's worthwhile.

Re: I was wrong about spreadsheets (2017)

#262

Post by brootstrap »

ubermonkey wrote: post #259

There's nothing WRONG with the spreadsheet model, and never has been. It's immensely powerful and useful, and the growth in capability over the life of a product like Excel is remarkable and enviable. Excel is perhaps Microsoft's greatest product. The problem with it -- and there IS a problem -- is really a problem of applicability. Excel, like Lotus before it, is the first place many people encounter the ability to…

Yeah i agree with you. Excel is very powerful to some degree but like all things it can be abused.

somewhere in a cube farm i can hear the shouts...

"Hey Karen did you get the latest budget sheet?"

"Is it budget_final_v2_2019.xlsx?"

"Damnit Karen that is from last week dear god dont tell me you sent that to corporate!! We are on budget_final_FINAL_v4.xlsx"

Re: I was wrong about spreadsheets (2017)

#263

Post by ubermonkey »

codeulike wrote: post #116

The thing about finance trader types removing the F1 keys from their keyboards so they don't accidentally press 'help' while using Excel at high speed says a lot about how handy Excel is (and how slow the Help loads)

Well, also about how unremittingly shitty F1 help is.

Googling the topic you need help on is invariably faster, even if all you really need is, say, the syntax to a given Excel function.

Re: I was wrong about spreadsheets (2017)

#264

Post by kirubakaran »

dvdsgl wrote: post #6

This is exactly why we're building https://glideapps.com !

Looks great! Wishing you all the best!

Few minor notes: - You've featured an app "Tournament of Books" but there are no links there. Both the title and the mock text conversation image can be links to that app - Interspersed fixed width font is jarring

Re: I was wrong about spreadsheets (2017)

#265

Post by ubermonkey »

brootstrap wrote: post #262
ubermonkey wrote: post #259

There's nothing WRONG with the spreadsheet model, and never has been. It's immensely powerful and useful, and the growth in capability over the life of a product like Excel is remarkable and enviable. Excel is perhaps Microsoft's greatest product. The problem with it -- and there IS a problem -- is really a problem of applicability. Excel, like Lotus before it, is the first place many people encounter the ability to…

Yeah i agree with you. Excel is very powerful to some degree but like all things it can be abused. somewhere in a cube farm i can hear the shouts... "Hey Karen did you get the latest budget sheet?" "Is it budget_final_v2_2019.xlsx?" "Damnit Karen that is from last week dear god dont tell me you sent that to corporate!! We are on budget_final_FINAL_v4.xlsx"

We see this A LOT in our implementations.

We sell & implement a project management financial metrics tool (supporting earned value analyss; google if curious). A key input is always the actual costs of work done, which has to come from the financial system of record.

A horrifying amount of the time, the actual path is through goofy undocumented Excel sheets, because nobody knows how to extract it natively from $FinSys.

Re: I was wrong about spreadsheets (2017)

#266

Post by jacobush »

mikekchar wrote: post #118
incongruity wrote: post #98

Earlier quoted context omitted.

It’s absolutely fair to blame excel. It obfuscates the code in favor of displaying the calculated values - it’s designed to hide the code - which, along with a number of other design decisions, makes it really hard to build an error free spreadsheet beyond trivial sized cases. Further, its design makes reproducible data practices difficult - in contrast to R or Python which do a lot to separate code from data - and l…

Ironically org mode in Emacs would be better in that respect :-)

I almost cracked the org-mode code. Almost. Used it for some sheets but now I only use it for my journalling. Hopefully it will keep the embers hot until I decide to pick it up for real again.

Re: I was wrong about spreadsheets (2017)

#267

Post by ekianjo »

phonon wrote: post #253
ekianjo wrote: post #241

Earlier quoted context omitted.

> 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…

> it does not support native UTF8 csv files It does though? You can export as a UTF-8 csv file...check the export options.

I am talking about importing CSV files in UTF8. If I use Japanese characters for example it fails utterly to display properly unless I import it as "Text" first.

Re: I was wrong about spreadsheets (2017)

#268

Post by ekianjo »

astine wrote: post #252
ekianjo wrote: post #241

Earlier quoted context omitted.

> 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…

Well if you're using Python, you're following an imperative/oop paradigm which goes back to the sixties, so I don't know why you'd criticize Excel for using a dataflow model. I can understand not wanting to use Excel because it's proprietary (but Libreoffice isn't) but I can can understand not wanting to deal with a lot of it's legacy cruft, but for the stuff that Excel does well, it does it a lot more quickly, more…

> that you can see every step of your calculation which creates a degree of self documentation which you don't get with Python, for example.

If you want to do that in Python then Jupyter Lab/notebook is a good solution to document your code and see the result of each operation. And way faster than Excel for large data tables.

Re: I was wrong about spreadsheets (2017)

#269

Post by shareIdeas »

Ah yes, the confident programmer that would DIY everything.

I feel like underestimating Excel is a classic example how an expert can have holes in their thinking.

With VBA, Excel becomes a ton more useful, adding programming. Excel is merely a visual database you can share with coworkers and encapsulate in a single file.

There is a time and place for everything. Excel is very useful for workplace data sharing and manipulation.

Re: I was wrong about spreadsheets (2017)

#270

Post by giardini »

Maybe.

Jocelyn Ireson-Paine has a deep knowledge of the problems and some solutions for spreadsheets:

https://johncarlosbaez.wordpress.com/2014/02/05/category-the...

Paine has long worked with the European Spreadsheet Risks Interest Group (eusprig.org) and has used category theory to develop a system in Prolog called Excelsior about which he says "Excel lacks features for modular design. Had it such features, as do most programming languages, they would save time, avoid unneeded programming, make mistakes less likely, make code-control easier, help organisations adopt a uniform house style, and open business opportunities in buying and selling spreadsheet modules. I present Excelsior, a system for bringing these benefits to Excel."

Examples of Excelsior:

"Less Excel, More Components: presentation to EuSpRIG 2008 [by] Jocelyn Ireson-Paine":

https://www.j-paine.org/eusprig2008/index.html

"Excelsior: bringing the benefits of modularisation to Excel":

http://j-paine.org/eusprig2005_pres/presentation.html

"Rapid Spreadsheet Reshaping with Excelsior: multiple drastic changes to content and layout are easy when you represent enough structure":

https://arxiv.org/pdf/0803.0163.pdf

Paine's home page:

http://www.j-paine.org

Paine's Safer Spreadsheet twitter:

https://twitter.com/SafeSpreadsheet

Post reply on HN