I would expect it to leave my data alone unless told so. It’s one of the little things that drive me crazy with Excel the few times I use it, and every time I need to search how to make it behave because I don’t use it nearly enough to remember.
I would expect it to store 01234 as a number unless explicitly told to store it as a string. This is exactly how it should work. I’m all for hating on excel but being upset because the software can’t read your mind and your eccentric edge case isn’t automatically picked up is a bit entitled
I would expect it to store 01234 as a number unless explicitly told to store it as a string.
These days I'd disagree. Once upon a time explicitly column delimited data with leading 0 padding may have been common, but I suspect in most software written in the last 20+ years leading 0s if included are more likely relevant parts of the data rather than Hollerith card default punches.
not what i'm saying. the vast majority of people who work with spreadsheets have no interest in redefining it to align with other paradigms. spreadsheets work damn well as they are
I think I want to do the opposite of reading my mind to be honest. The default cell type is generic, so just assume everything is a string and don’t do any parsing. Maybe show a tooltip to quickly change the cell type if you detect something that might be a number or a date.
Probably it’s just different usage - when I use excel is mostly to store a table of raw data where I want to store the actual data, not what excel thing the data is. I’m using it as the equivalent of a database, but simple to update and share with other people (even not technical folks) or to open a csv and quickly hide/filter some data.
> The default cell type is generic, so just assume everything is a string and don’t do any parsing.
So, if you have `1234` in A1 and `5678` in B1, `=A1+B1` should by default produce `VALUE ERROR` rather than `6912`?
That's... not why spreadsheets were invented.
> when I use excel is mostly to store a table of raw data where I want to store the actual data, not what excel thing the data is. I’m using it as the equivalent of a database,
Then use a database program, not a spreadsheet!
However, if there are no database programs that fit your needs, and you end up using a spreadsheet instead, don't complain that the spreadsheet acts like a spreadsheet instead of a database. It's not the tool's fault that you're the one using the wrong tool for the job.
Umm, if you are treating them as text cells, then adding them would product 12345678 since you are concatenating strings. I just don't think there is any good solution for this, since it's effectively impossible to automatically distinguish numbers that the user wants to treat as strings (like a zip code) and numbers that should be treated as floats or ints.
+ is not concatenation in any spreadsheet program I've seen, and it probably shouldn't be concatenation in anything. That's the solution, having a separate concatenation operator.
Tend to agree that choice of + for string concatenation was a mistake - anyone know the history/first widely used example? Did the original BASIC have it? (I think QuickBasic did, but that's unlikely to be the origin).
It's not just a syntactic difference. It's a huge UX difference that one operator always does an addition on both numbers and numeric strings, and another operator always concatenates both numbers and numeric strings.
The looser your typings the more it matters, and spreadsheets barely even have types.
+ is not a cancatenation operator in excel. It is numeric addition. It is added the numeric values of which the letter characters are merely a representation then that answer would be the same as if excel treated them as numeric data types.
Alternatively, if you don’t want excel to perform addition on underlying numeric values but instead only on defined data types then the formula could result in NaN which would signal to the user that the explicit data type was not compatible with addition.
I know, complaining like this probably doesn’t make sense. It’s a minor issue to begin with and I’m probably an edge case as far as excel users go. It doesn’t make sense for MS to tailor its product for my type of user.
Databases only have a fraction of the capabilities of a spreadsheet. That's not a reasonable response.
There’s nothing you can do in a spreadsheet that an RDBMS can’t do.
Programmers often object to spreadsheets because they’re too “brittle”. I don’t think it’s an unreasonable objection.
Most spreadsheet users don’t exhibit the rigor necessary to impose a schema on their spreadsheet-based data, nor to use features like named ranges to abstract away the physical location of data in the spreadsheet from its semantic meaning. Data validation is an afterthought, too. Spreadsheets invite silent errors when rows or columns are inserted or removed, data is copied/pasted, etc. It takes more effort, in my experience, to keep the formulae in a spreadsheet working in the face of modifications versus a database.
A database explicitly separates the data from logic (at least, typically— getting into queries that act conditionally based kn queried data blurs that line a bit) and provides a strong schema and enforced validation at the time data is added or modified. You’re not going to get wrong answers from a database query because somebody added a row at the bottom of a range that isn’t covered by a SUM(), for example.
...I logged back into my lurker account just because of how annoying this was- I use Google Sheets all the time to do data visualization and analysis work because it just works, and because I can share my results with other people, and let them explore the data in a format that they understand.
There's a reason lots of MBA types get issued high-performance, high RAM machines- because asking them to learn SQL or whatever AND asking them to learn how data structures and query syntax work instead of just doing things a little more slowly and throwing more performance at Excel makes a lot of sense.
Not saying it's perfect, but please don't hate on Excel et al because they aren't the perfect world way of doing things.
Spreadsheets are great for ad hoc work. I think they’re intuitive and agile. I use them for that purpose too. All the time.
Using them for business processes is a recipe for sadness. People don’t have the discipline to use them for that, and the tools have too many shortcomings.
In terms of “exploring data” I’ve been in way too many meetings where different users have worked on forks of the same original spreadsheet and come up with contradictory answers.
Re: slowing people down - I’ve had the fortune to show a few “MBA types” how to do JOINs in lieu of the eldritch horrors they’d created attempting to re-implement JOIN with VLOOKUP. The productivity gains were significant. Excel is using a screwdriver to drive nails in some very glaring cases.
> Using them for business processes is a recipe for sadness. People don’t have the discipline to use them for that, and the tools have too many shortcomings.
> In terms of “exploring data” I’ve been in way too many meetings where different users have worked on forks of the same original spreadsheet and come up with contradictory answers.
You shouldn't use a notepad of SQL statements for processes either!
Once certain things are figured out and planned around for repeated use, they need to be transformed into a proper maintainable form, probably involving careful code with error detection. But that's not a spreadsheet vs. SQL issue. If SQL causes fewer problems it's probably because someone that knows SQL is more likely to have programming knowledge/discipline, not something about SQL itself.
> Re: slowing people down - I’ve had the fortune to show a few “MBA types” how to do JOINs in lieu of the eldritch horrors they’d created attempting to re-implement JOIN with VLOOKUP. The productivity gains were significant. Excel is using a screwdriver to drive nails in some very glaring cases.
It's great to use a JOIN when it's appropriate. But a lot of the time there's still no real need for a database, and you want all the other tools a spreadsheet has. Or there is a good case for a database, but the best answer is having some queries that feed the spreadsheet.
And even if you do teach them proper database queries, that doesn't give you a nice editable view of multiple interlinked queries and parameters, with output organized into charts and graphs. The best option down that road isn't switching to a database program, it's using a spreadsheet program that can do SQL.
Everyone uses Excel as a database, and Excel should absolutely tackle this. It’s like “Everyone is using Toyota to carry children to schools in underdeveloped countries” so let’s put seatbelts, you know, even if it’s not the intended usage.
The French government believed that Covid cases had stopped increasing, because their federated Excel spreadsheet was silently truncating data at 1 million rows. Accidents like this happen all the time.
Access should be based on Excel, only adding sheet types: single-record forms, SQL reports, pivot tables.
In fact, pivot tables are the proof that Excel is a database tool.
> It’s like “Everyone is using Toyota to carry children to schools in underdeveloped countries” so let’s put seatbelts, you know, even if it’s not the intended usage.
WTF? Are you saying Toyota don't normally put seatbelts in their cars? Like... what???
Maybe, but it seems weird for it to be completely unreasonable for operator overloading to be a thing, but also expect the user to have a working knowledge of basic data types.
I think the usage to store other type of type is getting popular very late after excel has being invented.
It was created to count money. So it would make sense to defaults field to number unless it obviously isn't.
People are just using a tool that isn't designed for your current purpose.
I think probably the best change it can do is don't alter the data at input. Instead, alter it at display and compute. Then it won't actually corrupt your data anymore.
Then for a wrong field type, you just need to change the type, and the correct data will be displayed as expected.
They're weird in that they are text codes rendered exclusively in digits in the US. Most Americans are generally ignorant of this and blissfully input them as numbers and those in the east with leading zero codes have to deal with the blowback.
I don't care how it stores it but if I've input 01234 either manually or via a CSV import etc. I do expect it to remember that there was a 0 at the beginning.
Excel's lossy data type conversion has caused more problems than I care to remember over the years. One of them caused a significant sum of money to be deposited in the wrong bank account once.
Storing a zip code in a column of an excel file is by no means an eccentric edge case. If I type 01234 into a cell, it’s not unreasonable to expect excel to save it (and reproduce it in e.g. a mail merge) that way.
If I explicitly typed a leading 0, I want it to stay unless I'm typing it into a numeric cell. In that case I'm doing something strange and wasting my time but what I want is obviously 1234.
Why would anyone type a leading zero on a number? The only time I _ever_ do that are parts of dates, which this wouldn't hit, and octal numbers extremely rarely in code.
