If Excel had just a couple more features it could be much more ergonomic and not even need macros. Specifically: anonymous functions/lambdas made with just pure formulas. Define a function in a cell like `=($s) => [expr]` (or something idc). Call it with `=A1("string arg", B2:B100)` or by name if you name it via named ranges. Functions are obviously a new data type, so you can pass them as parameters to each other or to relevant builtins. It would turn Excel into some kind of hybrid pure functional/spatial language where the code itself is spatial data.
The typical things one gains from higher order functions are things like mapping and filtering of data structures. Excel only has one data structure—the table. Mapping is done by writing the formula once and then dragging it from the corner to the whole column. Filtering is not really done. Normally use the gui to hide the rows to be filtered away.
Functions add in questions of scoping. How are closures supposed to work? Could there be some way to say “the function in cell A1 at the time and closing over the state of when cell B2 was last logically computed”? Excel handles scoping in the non-function-in-cell approach using $.
Obviously this all breaks apart when you don’t want tables where you drag things either always down or always across
> Mapping is done by writing the formula once and then dragging it from the corner to the whole column. Filtering is not really done. Normally use the gui to hide the rows to be filtered away.
You should look into array formulas (or block formulas). They break out of the one-at-a-time mold and could be much more powerful.
Yes but it’s not done with a function like filter in scheme or Haskell, it’s done by the gui, outside of the world of formulas. For more complex stuff there are database features hidden away inside
You jest, but people really do underestimate Excel. Yes, it sucks - but there is a reason that despite all its flaws, people keep trying to use it for things. (And no, that reason is not "they're too stupid to learn how to code")
And I'm not sure the things that make Excel so crappy could really be fixed without sacrificing the things that make it such a flexible and useful tool. For instance, adding the ability to recurse or iterate sanely would remove the transparency of having every iteration of a computation clearly visualized cell-by-copy-pasted-cell.
For me it usually is "I would like to use some sensible tools, but corporate policy requires me to not do that (because they are not available) - so I have to (ab)use Excel/Office/VBA to get things done." It's not pretty, stable, efficient or really maintainable, but if you are forced to use a hammer..
ps. Excel does some things OK, like drawing pretty graphs on smallish datasets and visualize quick analysis with pivot tables. It just lacks a sensible scripting language and is generally very brittle once the data is getting nontrivial and more than one person is involved.
Excel-based workflows are definitely brittle, but people learn to be careful with it (you have to, if you want to keep your job).
One big problem it solves for regular people (i.e. not programmers) is this: "our workflow and/or reality of our business changes much faster than the IT department/outside contractors can keep up with".
(The other big, and related, problem is: "our IT department/outside contractors have no clue and don't really even care much about what we actually do or need".)
It's also really quite good for automating numerical calculations; a sort of poor-man's-Matlab. Having every intermediate value in a multi-step computation both immediately visualized (and thus easily sanity-checked) and accessible as a variable, without having to keep track of names, is very powerful.
I’ve been solving this problem with PowerShell for the last year or so. It’s usually available on locked-down corporate Windows boxes, and you can use the entire .NET Framework, as well as third-party .NET libraries, without admin rights. I’m using it with System.Data.SQLite to build a WPF application at the moment, which will hopefully replace a whole bunch of messy and hard-to-maintain Excel sheets and Access databases.
I love PowerShell for this reason. I had a 100 CSV files, and I needed the first two rows removed to put them into a signal viewing app, and it took only a few lines of PowerShell to do this on my corporate machine. I would normally do this in another PL, but strangely PowerShell's solution further pushed me to look into it for other uses on that machine. I wish there were a good book for this, since I actually prefer that than just Googling quick solutions when trying to actually learn something.
Yep, I could have learned much faster with a good book. Most PS tutorials are targeted at sysadmins with minimal programming experience. I would have preferred something that assumed programming experience and focused on what makes PS different from other scripting languages.
I work in a Microsoft shop, but I always have a bash shell running. It prevents me from really diving into PowerShell. I will end up running a quick sed '2,3d' on the csv files and move on with my life.
I have PowerShell on my local company machine, and without Admin priveleges I can't even sideload bash through a Git install. We're not a software company, so requesting Git is also out of the standard operational procedures as a user. IT knows my coding background (since 1978), but they can't change policy.
I work at an engineering firm (not software), and for performing and presenting manual calculations it it great. You wouldn't write a Python or Julia script or use a Jupyter notebook for any of it. Because I like to code, I've written small programs for more involved calculations in J, C, F#, and my favorite Frink. Frink is great for engineering because it handles different units and systems throughout a calculation. Mathcad is also good for laying out manual calculations. Excel is the engineer's scratchpad. There are just certain things that are just easier to do in Excel, and not everything turns into a problem that needs a programming language. But there are ways of working with Excel from most programming languages aside from VBA.
A lot of Excel's issues are well-known because of how pervasive it is. Python and kin rely on C libraries and other layers of imported packages for numerical work that can lead to all sorts of numerical mischief. Even doing:
round (2.575, 2)
in Python leads to 2.57 instead of rounding up to 2.58. Everything in our engineering firm is checked by another engineer.
The behavior of round() for floats can be surprising: for example, round(2.675, 2) gives 2.67 instead of the expected 2.68. This is not a bug: it’s a result of the fact that most decimal fractions can’t be represented exactly as a float.
> Yes, it sucks - but there is a reason that despite all its flaws, people keep trying to use it for things
Yes, but the main one is that institutional IT policies frequently dictate that people whose aren't employed specifically in software development roles aren't allowed software development tools, but everyone in the org tends to be allowed core Office apps like Excel.
When it's literally the only remotely applicable tool most people are allowed to have, it shouldn't be surprising that it gets used for a lot, independent of merit.
you can recurse in excel. its disabled by default but you can set the max depth on circular references in some menu. I haven't used it since the 2007 version