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

311–320 of 378 posts

Re: I was wrong about spreadsheets (2017)

#311

Post by chaostheory »

jacobolus wrote: post #73
chaostheory wrote: post #63

Earlier quoted context omitted.

Access and FileMaker made sense before the advent of open source, specifically Rails. Django, Postgresql, and MySQL. Both products make little sense now.

> Rails. Django, Postgresql, and MySQL These are much harder for non-programmers to use than Access. With Access, almost completely non-technical people can set up their own database and make the queries they need to answer their own questions. With Postgres accessed from a general-purpose programming language, non-technical people need to hire someone to help them with every basic task. As far as I can tell Access h…

> As far as I can tell Access has nothing to do with making websites, so it’s unclear what Django or Rails has to do with anything.

You can make apps with Django and Rails. They're not just "websites". Web apps are also still useful even when they're not public facing.

> These are much harder for non-programmers to use than Access. With Access, almost completely non-technical people can set up their own database and make the queries they need to answer their own questions.

That's the thing. Access and FileMaker aren't typically run by non-technical people. Yes, they aren't initially programmers, but they're usually technical people. FileMaker & Access users, whether they realize it or not, become programmers. I feel that you're confusing Access & FileMaker users with users of Excel.

> With Postgres accessed from a general-purpose programming language, non-technical people need to hire someone to help them with every basic task.

A relational database is not a big leap from either Access or FileMaker.

I know all of this because I used to work closely with a team of these people, and at some points I've even helped maintain their code.

Re: I was wrong about spreadsheets (2017)

#312

Post by jvanderbot »

behringer wrote: post #295
swiley wrote: post #286

Earlier quoted context omitted.

I’m not convinced there’s a such thing as “correct usage of excel.” What a lot of companies do is just scare entry level employees into being very careful. My friend’s girlfriend works at a place like this and people just accept all the problems with manually editing large spreadsheets because “that’s just life.” Anything in excel is a hack and most of its users don’t know any better.

What's your solution? That the manager who wanted some report comes to you and begs you to do it and in 6 months it's finally delivered and all wrong?

The sweet spot where I work is online forms that pre-populate excel playgrounds and allow download. Then, you can tweak till your heart's content.

Re: I was wrong about spreadsheets (2017)

#313

Post by _bxg1 »

I think one of the main takeaways is: included batteries are underrated. This is seemingly one of the main appeals of Python.

Another is: an integrated solution that's been designed holistically, instead of blindly assembled out of modules, does wonders for reliability. See: the difficulty of setting up a JS build environment vs a Rust build environment. Also, the success of Atom vs VSCode.

Re: I was wrong about spreadsheets (2017)

#314

Post by 6gvONxR4sf7o »

For the last few years I've believed Excel is the most important piece of software written, no hyperbole. The reason is that it's so damned accessible. Software is eating the world, and letting people who don't write "true" code still kinda write code opens up software's productivity and automation benefits for a bunch of use cases and an insane amount of people.

For programmers, the analogy is python. It's almost never the best tool for any specific thing, but it's a really solid tool for a ton of things. It's easy enough to learn and has enough depth to keep learning. It's easy to prototype a quick answer, and can not-to-painfully grow to a large complex system. I think that's why you get people from all backgrounds using python. It enables people who don't know much about software to start writing software.

Excel's the same way, but with an even lower barrier (and probably lower ceiling). It enables people who don't know anything about software to get many of software's benefits. That's huge.

Just like python can great for a biologist whose focus is biology not software, Excel is great for the accountant whose focus is accounting, not software. It makes them a programmer, or at least close enough for many many purposes.

Re: I was wrong about spreadsheets (2017)

#315

Post by marcosdumay »

qwerty456127 wrote: post #156
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.

+1000. This is ridiculous. Couldn't they at least make this optional so you'd be able to switch this off somewhere in the configuration dialog, registry or command line? I hate localized apps altogether (who even needs localized Visual Studio srsly? I can't believe anybody can be competent in a .Net programming language and relevant frameworks and practices without being able to read English) but localizning some app…

> who even needs localized Visual Studio srsly?

What's not to like on Oracle's localized error messages that you can't google because all the documentation is in English?

Even more because some on my language omit useless words like the equivalents of "not" or "can't".

Re: I was wrong about spreadsheets (2017)

#316

Post by michaelper22 »

mirimir wrote: post #93
MooMooMilkParty wrote: post #55

Earlier quoted context omitted.

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

In MySQL, maximum row size for non-text columns is 65,535 bytes. MySQL is limited to 4096 columns per table, and 1017 columns per table if the InnoDB engine is being used. Excel's limits are 16384 columns and 1048576 rows. I'm talking wimpy hardware here, I admit. Basically, VirtualBox VMs on a quad-core i5 box with SSD and 8GB RAM. With the VM having three cores and 6GB RAM. But it was the same wimpy hardware for Wi…

Notwithstanding the row length and column count limits, did you also give MySQL more memory? Setting InnoDB buffer pool size to 3 or 4 GB might help; its default is about 134 MB.

Re: I was wrong about spreadsheets (2017)

#317

Post by magicnubs »

tonygrue wrote: post #43
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'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 su…

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

Didn't they add Javascript support in 2018?

I agree though. They brought up that they were considering Python3 integration like 2 years ago and haven't said a word about it since.

Re: I was wrong about spreadsheets (2017)

#318

Post by marcosdumay »

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.

The usual out of hand Excel file has a completely different size from the usual out of hand codebase.

Re: I was wrong about spreadsheets (2017)

#319

Post by gclaugus »

I've been doing Excel and VBA work for my internship this summer, and I have to say, I have an immense amount of respect for the engineers behind Excel. Excel is incredibly extensible, it has very nice built-in error handling for mangled data (but horrible exception handling in VBA), and overall it is simply a joy working with it.

Sure, it has some pain points, but for my use case (financial analysis), it complements Bloomberg very well. Bloomberg's Excel add-in is very well-engineered, and there is even a way to hook into Bloomberg through VBA. Cheers to the MSFT devs who crafted this stuff.

Re: I was wrong about spreadsheets (2017)

#320

Post by jacobolus »

chaostheory wrote: post #311
jacobolus wrote: post #73

Earlier quoted context omitted.

> Rails. Django, Postgresql, and MySQL These are much harder for non-programmers to use than Access. With Access, almost completely non-technical people can set up their own database and make the queries they need to answer their own questions. With Postgres accessed from a general-purpose programming language, non-technical people need to hire someone to help them with every basic task. As far as I can tell Access h…

> As far as I can tell Access has nothing to do with making websites, so it’s unclear what Django or Rails has to do with anything. You can make apps with Django and Rails. They're not just "websites". Web apps are also still useful even when they're not public facing. > These are much harder for non-programmers to use than Access. With Access, almost completely non-technical people can set up their own database and…

> I feel that you're confusing Access & FileMaker users with users of Excel.

I know several people who use or used Access / Filemaker who were non-technical with previous experience mostly consisting of Word / light Excel use.

For example, my anthropologist parents used Access for analyzing their manually gathered census data for a small rural village.

The volunteer docents at a local museum in my hometown used Filemaker for managing the museum collection.

> whether they realize it or not, become programmers

Using the graphical tool in Access to construct queries does not require becoming a proficient programmer.

> A relational database is not a big leap from either Access or FileMaker

These are relational databases. They just have user interface affordances intended for non-technical users. Postgres does not.

Post reply on HN