5 ms·

> People refuse to stop using Excel because it empowers them and they simply don't want to be disempowered. That is not always true in my experience. Many peop

by Zababa 5y ago

> People refuse to stop using Excel because it empowers them and they simply don't want to be disempowered. That is not always true in my experience. Many people use Excel because it's one of the two programming tools allowed by the IT department, the other being a web browser. Even if you manage to install Python or something (good luck getting the package management working from behind your corporate proxy), your collegue will not have it, so it's useless. And distributing executables is usually not tolerated either. So you use excel, and share Excel files. I'll add that another big problem I have with Excel is usually the lack of database support. Moving data around by copy/pasting it in Excel with macros is a pain, and IT didn't allow Microsoft Access either so I can't comment on that. But I think it would have made my life easier.

JohnnyHerz 5y ago
If you substitute "spreadsheet" for "Excel" than i agree. But i have tried everything possible to avoid Excel as every iteration just brings new problems instead of fixes. I used Clarisworks years after it was EOL and now am trying very hard to convert to Libreworks. Admittedly i can't completely escape Excel yet, but i am hopeful and it's getting to the point where the bugs in Libreworks are no worse the bugs in Excel. If not for all the Legacy Excel sheets i have, i'd be off it completely.
dan-robertson 5y ago
I somewhat disagree. I work with a lot of excel power users. We have some massive spreadsheets which are collaboratively worked on and do complicated things. The first thing to say about them is that they are very valuable to the business so it is important to be able to do some of the things excel does. Excel has a lot of advantages compared to regular programming: - It is quick to change. The programs I work on take nearly an hour to go from code review completion to production, even with manual poking to speed up continuous deployment. It can be valuable to be able to change things quickly. - In excel the main thing you interact with is the data. If you are a domain expert then you should be able to look at outputs and see if they seem right. When you change a formula or add a column, you are, in some sense, also getting to run it on realistic data instead of needing to try to construct realistic tests. - There isn’t much difference between config parameters and hard coded values. In the programming language I use, you can’t really have globally readable configs so any new parameter must be threaded through from app startup to the place you want to use it, discouraging configuration parameters. Which means it is often slow to change something that ought to have been configurable. In excel you can make a quick cell for some Config parameter (changing a lot of formulas is not so fun though.) - Functional and declarative, Excel tends to give you internally consistent output. There is less need to worry about incorrect state updates. - Its maybe better for producing graphs. I never really liked making graphs in excel and I thought the defaults were bad for good data visualisation but then other systems have bad defaults (when I draw a graph I often use GNU Calc with gnuplot…) - Pivot tables are great for ad-hoc analysis (indeed Excel is pretty good for as-hoc analysis in general.) The pivoting operation is trivial in excel and a big pain to with tools like grep or awk or sed. These Excel users are generally capable of programming too and may use jupyter notebooks with python or R, or something more fully featured when required. And some things will get outsourced to software engineers, but excel is still clearly useful (so long as it scales) and people don’t just use it because they are desperate for some kind of ‘real’ programming language.
- brundolf 5y ago
  To be honest half of these points sound like company process issues (you can make changes quickly with code, just not with this particular review process/CI), and half of them sound like programming-language issues (lots of languages are functional and/or let you make a quick global config parameter)
  - dan-robertson 5y ago
    It’s never so simple. I use a functional programming language but generally in functional programming you don’t want to have global configs but rather to pass functions the things they need. Compilation is mostly fast but there is a lot of code (and we get roughly exponentially faster at building it. The problem is that we also have an exponentially increasing codebase.) Faster deployments could be possible (eg deploying dev builds rather than release builds made in the standard way) but it’s better to have the system work automatically and sensibly in the ordinary case than to try to support quick changes in the extraordinary case. It’s not really a good practice to support deploying random binaries of unknown origin, and certainly not great to do it routinely.) To be clear, excel can have scaling issues too (as well as issues with multiple people trying to change a single sheet) and we ended up recreating some excel-like features in some of our own applications.
- Zababa 5y ago
  I agree, what I shared was mostly my experience with Excel. We did mostly lots of data transformation, and for that it was far from ideal. But for your use case, it seems great. My father works as a CFO and uses Excel in the way you describe it, and it's really hard to find a better tool for the task. There is another limitation that I forgot to mention: if you are not using Windows, you don't have acces to Pwoer Query and things like that, so for huge datasets, Excel becomes very slow.
technion 5y ago
As a counterpoint, I'm supporting a lot of corporate environments and I'd love if just one user anywhere expressed a desire to use Python. I've encouraged people look at it several times, along with R Studio or anything else that might help. But politically it won't happen. So instead, I get handed badly coded Excel macros and told "there's a server problem", or a document that just slides in the 2GB limit by a few KB and told "it's a bit slow".
- blitzar 5y ago
  > badly coded Excel macros I think you mean badly recorded Excel macros. A lot of problems, and their solutions have been rethought in the form of excel. Rows, columns and sheets, copy/paste pivot. As much as I detest excel, it does have its place. At a 2gb file size however, that place doesnt really exist anymore.
pjmlp 5y ago
If they look around enough, there is also VBScript, JScript, Powershell, and basic C# and VB.NET compilers as well. Naturally it depends how locked down the domain policies are.
zhte415 5y ago
> I'll add that another big problem I have with Excel is usually the lack of database support. SharePoint site as the backend. Spare PC in a cupboard somewhere chugging away as a substitute for cron, or if you want to updating a spreadsheet middle layer that the dumb terminal sheets connect to via a shared drive... with a script running simulating moving the mouse so the mandatory screensaver timeout doesn't kick in. Been there, done that.

by Zababa 5y ago

JohnnyHerz 5y ago

If you substitute "spreadsheet" for "Excel" than i agree. But i have tried everything possible to avoid Excel as every iteration just brings new problems instead of fixes. I used Clarisworks years after it was EOL and now am trying very hard to convert to Libreworks. Admittedly i can't completely escape Excel yet, but i am hopeful and it's getting to the point where the bugs in Libreworks are no worse the bugs in Excel. If not for all the Legacy Excel sheets i have, i'd be off it completely.

dan-robertson 5y ago

I somewhat disagree. I work with a lot of excel power users. We have some massive spreadsheets which are collaboratively worked on and do complicated things. The first thing to say about them is that they are very valuable to the business so it is important to be able to do some of the things excel does. Excel has a lot of advantages compared to regular programming: - It is quick to change. The programs I work on take nearly an hour to go from code review completion to production, even with manual poking to speed up continuous deployment. It can be valuable to be able to change things quickly. - In excel the main thing you interact with is the data. If you are a domain expert then you should be able to look at outputs and see if they seem right. When you change a formula or add a column, you are, in some sense, also getting to run it on realistic data instead of needing to try to construct realistic tests. - There isn’t much difference between config parameters and hard coded values. In the programming language I use, you can’t really have globally readable configs so any new parameter must be threaded through from app startup to the place you want to use it, discouraging configuration parameters. Which means it is often slow to change something that ought to have been configurable. In excel you can make a quick cell for some Config parameter (changing a lot of formulas is not so fun though.) - Functional and declarative, Excel tends to give you internally consistent output. There is less need to worry about incorrect state updates. - Its maybe better for producing graphs. I never really liked making graphs in excel and I thought the defaults were bad for good data visualisation but then other systems have bad defaults (when I draw a graph I often use GNU Calc with gnuplot…) - Pivot tables are great for ad-hoc analysis (indeed Excel is pretty good for as-hoc analysis in general.) The pivoting operation is trivial in excel and a big pain to with tools like grep or awk or sed. These Excel users are generally capable of programming too and may use jupyter notebooks with python or R, or something more fully featured when required. And some things will get outsourced to software engineers, but excel is still clearly useful (so long as it scales) and people don’t just use it because they are desperate for some kind of ‘real’ programming language.

brundolf 5y ago
To be honest half of these points sound like company process issues (you can make changes quickly with code, just not with this particular review process/CI), and half of them sound like programming-language issues (lots of languages are functional and/or let you make a quick global config parameter)
- dan-robertson 5y ago
  It’s never so simple. I use a functional programming language but generally in functional programming you don’t want to have global configs but rather to pass functions the things they need. Compilation is mostly fast but there is a lot of code (and we get roughly exponentially faster at building it. The problem is that we also have an exponentially increasing codebase.) Faster deployments could be possible (eg deploying dev builds rather than release builds made in the standard way) but it’s better to have the system work automatically and sensibly in the ordinary case than to try to support quick changes in the extraordinary case. It’s not really a good practice to support deploying random binaries of unknown origin, and certainly not great to do it routinely.) To be clear, excel can have scaling issues too (as well as issues with multiple people trying to change a single sheet) and we ended up recreating some excel-like features in some of our own applications.
Zababa 5y ago
I agree, what I shared was mostly my experience with Excel. We did mostly lots of data transformation, and for that it was far from ideal. But for your use case, it seems great. My father works as a CFO and uses Excel in the way you describe it, and it's really hard to find a better tool for the task. There is another limitation that I forgot to mention: if you are not using Windows, you don't have acces to Pwoer Query and things like that, so for huge datasets, Excel becomes very slow.

technion 5y ago

As a counterpoint, I'm supporting a lot of corporate environments and I'd love if just one user anywhere expressed a desire to use Python. I've encouraged people look at it several times, along with R Studio or anything else that might help. But politically it won't happen. So instead, I get handed badly coded Excel macros and told "there's a server problem", or a document that just slides in the 2GB limit by a few KB and told "it's a bit slow".

blitzar 5y ago
> badly coded Excel macros I think you mean badly recorded Excel macros. A lot of problems, and their solutions have been rethought in the form of excel. Rows, columns and sheets, copy/paste pivot. As much as I detest excel, it does have its place. At a 2gb file size however, that place doesnt really exist anymore.

pjmlp 5y ago

If they look around enough, there is also VBScript, JScript, Powershell, and basic C# and VB.NET compilers as well. Naturally it depends how locked down the domain policies are.

zhte415 5y ago

> I'll add that another big problem I have with Excel is usually the lack of database support. SharePoint site as the backend. Spare PC in a cupboard somewhere chugging away as a substitute for cron, or if you want to updating a spreadsheet middle layer that the dumb terminal sheets connect to via a shared drive... with a script running simulating moving the mouse so the mandatory screensaver timeout doesn't kick in. Been there, done that.