I was wrong about spreadsheets (2017) • Hacker News Board

Re: I was wrong about spreadsheets (2017)

#51

Post by jedberg » Fri, Jul 12, 2019, 5:08 AM UTC

For a long while, my dad's job was as a consultant, and his job was to convert Lotus spreadsheets to Excel spreadsheets (and sometimes small databases). That was it. The spreadsheets he worked on were responsible for moving millions and millions of dollars around.

One of his jobs was for a major movie studio updating their sheets that calculated royalty payments. Every actor that ever worked on a show distributed by that studio relied on the accuracy of that single spreadsheet for their "money mailers".

Re: I was wrong about spreadsheets (2017)

#52

Post by dymk » Fri, Jul 12, 2019, 5:11 AM UTC

_coveredInBees wrote: post #50

dymk wrote: post #39

I can bundle my work in an iPython/Jupyter notebook, and if I'm feeling really frisky, I can package that in a Docker container. I expect anybody with a computer can now replicate my work, and not pay the cost of an Microsoft Excel license.

The Venn diagram of people who can spin up docker containers + Jupyter notebooks vs. people who prefer to use Excel for similar scenarios has very little overlap...

Yes, that's why the statement "Reactive programming is useful" is interesting to me, and "You should model your problems in Excel" is not. The article makes both points, and I disagree with the second.

This specifically is nonsense in the article:

> From there, you can calculate literally anything, and transmit not only the results of those calculations, but the actual environment itself, to anyone in the world, and expect that if they have a computer, they can replicate your results.

I certainly can not expect that people I'm interested in have Excel. I don't even have Excel.

Re: I was wrong about spreadsheets (2017)

#53

Post by xvilka » Fri, Jul 12, 2019, 5:11 AM UTC

There is LibreOffice Calc, which allows you to program it with Python[1]. Best of the both worlds. I recently created a suggestion [2] to support also Julia language in it. Hopefully they will consider it.

[1] https://wiki.documentfoundation.org/Macros/Python_Design_Gui... [2] https://bugs.documentfoundation.org/show_bug.cgi?id=125728

Re: I was wrong about spreadsheets (2017)

#54

Post by j88439h84 » Fri, Jul 12, 2019, 5:12 AM UTC

thanatosmin wrote: post #15

Is there anything like a spreadsheet to Python converter, with cells becoming made up variable names? I wonder if it’d be useful for quickly noodling together a set of expressions, then “baking” it into code.

pandas

Re: I was wrong about spreadsheets (2017)

#55

Post by MooMooMilkParty » Fri, Jul 12, 2019, 5:13 AM UTC

mirimir wrote: post #33

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…

On the same hardware, with the same table, Excel in Windows 7 does a cross-tab faster than MySQL in Ubuntu does. Indeed, MySQL chokes if there are more than a few hundred columns, but Excel just keeps going. And it uses all CPU cores. Edit: In case anyone is wondering why I did that, I wanted a simple visualization of ping-location results for thousands of IPv4 from several hundred ping-probe locations. So that meant…

You're blowing my mind here a little bit. I don't use MySQL but do use Excel and the R/Python data science stacks quite a bit. I regularly open data with tens or even hundreds of thousands of columns in the latter by using lazy computations. Is this not the case with database approaches? What kind of hardware are we talking? Presumably Excel has to load everything into memory at once since it's immediately viewable, right?

Re: I was wrong about spreadsheets (2017)

#56

Post by chaostheory » Fri, Jul 12, 2019, 5:13 AM UTC

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…

> The challenge many programmers face is thinking that every business problem is best solved with code, when in reality the majority are solved faster, more efficiently, and more maintainably with a spreadsheet.

It's not like you can't do both. Excel supported VBA macros for a long time. Now it supports JavaScript.

Re: I was wrong about spreadsheets (2017)

#57

Post by chaostheory » Fri, Jul 12, 2019, 5:14 AM UTC

viraptor wrote: post #40

sheetjs wrote: post #32

Earlier quoted context omitted.

We ( https://sheetjs.com/ ) almost exclusively deal with those types of complex applications built in spreadsheets > they could be improved a lot with minimal changes They can be improved for very specific use cases at the expense of others. > 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 organi…

> You either enforce the constraints and weaken the platform, or you give users the power to do what they want. I disagree with that. All the pieces are already there. There's nothing to weaken by education. But nothing tells the new users about them. They see the main screen and rarely ever know about multiple sheets. I've seen people using excel at work for years without knowing that. You don't have to take anythin…

You're both right. From experience, some people are happy to learn new things. Others, as sheetsjs pointed out, are not interested.

Re: I was wrong about spreadsheets (2017)

#58

Post by jedberg » Fri, Jul 12, 2019, 5:16 AM UTC

dymk wrote: post #46

jedberg wrote: post #42

Earlier quoted context omitted.

After I set up a Jupyter server and/or docker. With Excel, chances are I either have it on my computer, it is a single click download away, or I have another program already on my computer that can open it.

I certainly don't have Excel installed on my computer. It's not even free. And it's far harder for me to install it compared to free software, like Docker or Python (for which I can just type `brew install ...`). If you own a Mac, it's already got Python installed on it.

If you own a Mac then it comes with Numbers which can open Excel spreadsheets.

Also: `brew cask install microsoft-office`

Re: I was wrong about spreadsheets (2017)

#59

Post by chewxy » Fri, Jul 12, 2019, 5:17 AM UTC

wutbrodo wrote: post #36

chewxy wrote: post #25

Earlier quoted context omitted.

There's a term that's gaining popularity in the last 15 years: reactive paradigm of programming.

Is what we're talking about any different from declarative programming? That term has been in use for several decades

The portion of comment I was replying to was "no start or end" . This is reactive programming.

Having said that, other than Excel and some cute UI things, I've not seen much utility in reactive paradigms. Hence I am bearish on reactive programming. Someone please correct me.

Re: I was wrong about spreadsheets (2017)

#60

Post by sheetjs » Fri, Jul 12, 2019, 5:18 AM UTC

MooMooMilkParty wrote: post #55

mirimir wrote: post #33

Earlier quoted context omitted.

On the same hardware, with the same table, Excel in Windows 7 does a cross-tab faster than MySQL in Ubuntu does. Indeed, MySQL chokes if there are more than a few hundred columns, but Excel just keeps going. And it uses all CPU cores. Edit: In case anyone is wondering why I did that, I wanted a simple visualization of ping-location results for thousands of IPv4 from several hundred ping-probe locations. So that meant…

You're blowing my mind here a little bit. I don't use MySQL but do use Excel and the R/Python data science stacks quite a bit. I regularly open data with tens or even hundreds of thousands of columns in the latter by using lazy computations. Is this not the case with database approaches? What kind of hardware are we talking? Presumably Excel has to load everything into memory at once since it's immediately viewable,…

> Presumably Excel has to load everything into memory at once since it's immediately viewable, right?

Depends on the file format. An XLS or XLSB file can contain special markers for where each logical row starts, so it can randomly access rows; Both also can persist "calculation chains, which are a simplified dependency graph. The binary formats also store formulae in a parsed representation allowing easy scans to see what cells have to be inspected if a file needs to be recalculated.