Live data from Hacker News

I was wrong about spreadsheets (2017)

reifyworks.com

41–50 of 378 posts

Re: I was wrong about spreadsheets (2017)

#41

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…

Can I ask, what is "critical infrastructure planning"? Googled it, but wasn't sure as it appears to transcend many contexts.

I would guess something like transport (train network) or maybe utilities (power grid)?

Re: I was wrong about spreadsheets (2017)

#42
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.

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.

Re: I was wrong about spreadsheets (2017)

#43

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'd be over the moon to see one change to Excel. Native support for a language other than VBA. Perhaps the CLR. Perhaps Java/Typescript. Just something (optional) for programmers who want to use Excel and not want to deal with the garbage that VBA is.

Some workarounds exist, but afaik they require collaborators to also have the tool install, which is dead in the water.

I know MS has considered it, I'm still pretty surprised they've haven't followed through.

Re: I was wrong about spreadsheets (2017)

#44
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

Reactive programs don't have to be declarative. You can express a reactive program imperatively.

The defining feature of a reactive program is that relationships between inputs and outputs are automatically tracked, and changing an input will automatically update the dependent outputs.

Facebook had a whole experimental language (now abandoned) for writing reactive programs with imperative code: http://skiplang.com/

Re: I was wrong about spreadsheets (2017)

#45
> 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 think this is the real secret. It's really the only kind of "model" where the environment travels with it. Everyone has the same Excel setup. If it works for you it will work for them.

Re: I was wrong about spreadsheets (2017)

#46
post #42
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.

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.

Re: I was wrong about spreadsheets (2017)

#47

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.

I’m having ptsd right now of hidden ranges or random formatting from the end of the sheet becoming variables.

Re: I was wrong about spreadsheets (2017)

#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."

Re: I was wrong about spreadsheets (2017)

#49
Spreadsheets are the best -- specifically Google Sheets. The addition of QUERY really allows Sheets to be superior to Excel, at least for the things I use it for.

Combine that with an IMPORTJSON script, and you can create really clean, structured data sets for nearly anything you can dream up. I've been tracking movies and TV shows, for instance. Combining a few of the APIs out there to get the best possible results really makes the set shine.

I don't code beyond modifying basic things, but I rarely find something I cannot do with a spreadsheet.

[1] https://github.com/bradjasper/ImportJSON/blob/master/ImportJ...

Re: I was wrong about spreadsheets (2017)

#50
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...
Post reply on HN