It turns out that not having to name things is a feature. Users often avoid naming things and dislike being forced to do so.
The reason is what developers already know: naming things is hard! (Two hard problems, etc.)
Of course, developers also know how valuable good names are, so we like to take the time to pick good names. Users would rather just skip naming altogether and refer to things by letter/number or just by clicking on them.
>It turns out that not having to name things is a feature.
I think this is one of those great insightful points that's counterintuitive and yet has abundant real-world evidence we can't deny.
I'd guess that vast majority (99%) of programmers that program in languages requiring explicit variable names (Python, C, Java, Go, etc) will still use Excel without named cells nor named columns. Yes, they will label their adjacent cells with freeform text (e.g. "TOTAL PRICE:") but they won't use the Excel "named regions" feature to be referenced in formulas. How do we reconcile the inconsistent attitude we have about the benefits of names?!?
It turns out that yes, naming cells is a form of "code documentation" and helps avoid "spaghetti formulas" -- but it's also a friction. If programmers using Excel eschew cell names, it's a given regular users will too.
It also doesn't help that "names" in Excel is not a 1st class feature. It's a separate menu item and the name is a hidden "alias" for the cell.
With other products, the "name" of the cell is what you type into the box right there on the sheet. The UI for giving a cell a name is more immediate.
Range names come at a price. Try copying a sheet into another workbook that has conflicting names. Or copy-pasting your table in the same sheet to do something slightly different.
I use excel a lot and I found that the only convincing use case for range names is if you need to refer to ranges from VBA, then this is the only way for the code to find its way on a spreadsheet even if someone inserts some rows and columns. Otherwise range names create more problems than they solve.
We are designing nothing, excel allows you to create variables with names assured unique in a namespace(A single spreadsheet). You could use it any way you like.
But if you are copying a formula that has things like variable names into a new sheet, you have to understand that pasting the formula with its variables pointing to nothing is like inducing a NullPointerException.
//B1 is renamed as first
//B2 is renamed as second
_______________
f(x)| C3 = first * second
_______________
A | B | C | D
_______________
1|___|_2_|___|__
2|___|_3_|___|__
3|___|___|___|__
4| | | |
vs
_______________
f(x)| C3 = B1 * B2
_______________
A | B | C | D
_______________
1|___|_2_|___|__
2|___|_3_|___|__
3|___|___|___|__
4| | | |
It barely matters if you copy paste the first one or second one into a new sheet. C3 will be pointing to null. If anything its easy to trouble shoot former because you can chose any cell in the spreadsheet and call it 'first', chose another and call it 'second'- Compared to say to having fixed cells B1 for first and B2 for last.
I didn't know excel allowed you to assign names to cells. Nobody taught me so. Of course I'd find it useful if the UI for that feature was easy to reach.
In programming the UI to assign names is very intuitive and right there in your face. You place the name next to the thing you want to have named. Done.
In Excel it is both, very accessible and not obvious at the same time.
At the top left corner of the sheet, just to the left of the formula bar, there is a textbox that displays the cell Number (eg. A1). Simply click on that and enter a name for that cell.
But the fact that people routinely do create labels for cells, and have columns with headers is also a hint that the people are willing to name things.
So it does come down to a UI issue after all: the right UI for getting users to name things is one they want to use for labels/headers.
Yes, clicking on "this thing right here!" is a powerful way for ordinary users to create references. It shouldn't be underestimated.
Programmers are so used to having to name things that we don't see the mental overhead of using names. A named cell is conceptually a pointer -- you can change what it points to (by giving the same name to some other cell instead), and if you delete the referent, it can point to nothing. That kind of invisible indirection is not easy for non-programmers.
An important thing about cell references that makes them almost but not quite entirely unlike pointers is that they can be relative, absolute, or mixed.
Aren’t named cells/columns a category of their own? They’re not relative nor absolute, but resolved by the name binding that exists at evaluation time.
This is on top of the glaring issue that, if my formula says multiply "itemCount" by "itemPrice"... Where do I actually find those things? If I see A2 referenced, I know exactly where to find it.
that is exactly the reason why developers dont get the naming/not naming conundrum, A2 is a better name than itemCount and a better way to reference when dealing with hundreds if not thousands of variables, the advancement would be actually the ability to autoname vars and then allow users to rewrite them in case of inaccuracy, and also still allow for coordinate mapping bringing the best of both worlds
The reason is what developers already know: naming things is hard! (Two hard problems, etc.)
Of course, developers also know how valuable good names are, so we like to take the time to pick good names. Users would rather just skip naming altogether and refer to things by letter/number or just by clicking on them.