It works fine if the user is ok with the features from 2003. E.g. Excel 2003 is limited to smaller spreadsheets of 65536 rows by 256 columns but Excel 2007+ can handle larger worksheets of 1048576 rows by 16384 cols.
I also recently used Excel's new LAMBDA() function which was introduced 2020. In earlier versions, it required writing a VBA UDF to accomplish the same task of assigning a temp variable with a ephemeral value to calculate on intermediate values. VBA is a workaround but LAMBDA() is nicer to use because Excel will throw up scary security warnings whenever the xls file containing VBA macros is opened.
I might be able to get by with Word 2003 more than Excel 2003.
You're right about Excel; however, I think big data files should be handled in a db rather than in a spreadsheet. And sqlite can query Excel files (with an extension), and it's super fast and you can use any function you want, or write your own.
>; however, I think big data files should be handled in a db rather than in a spreadsheet. And sqlite can query Excel files (with an extension)
A lot of normal users of Excel are not users of database software like SQLite or MS Access. That's too cumbersome. E.g. they download a csv file that has ~100000 rows (which really isn't that "big") and clicking on it gets them an instant visual grid as a GUI in Excel. Slicing & dicing and pivoting data is way faster in Excel than coding SQL WHERE GROUP BY statements. I've commented previously on why databases are not substitutes for the workflow ergonomics made possible by spreadsheet tools : https://news.ycombinator.com/item?id=30987638
It's similar to reasons why Python/R or Jupyter notebooks are also not substitutes for Excel for the typical users of Excel.
The low row count of 65536 in Excel 2003 was just a legacy limitation of 1980s 16-bit computing that was carried over into 32-bit computing for many years for backwards compatibility reasons. Spreadsheet users don't really want to switch to databases or Python just to get more usable rows than 65536.
> The scenario of "I just sent you an xlsx where the rows highlighted in red are problems and if you can just add your notes to column K, that would be great. Thanks!" -- is not easy in other tools that are not spreadsheets.
There are no words to tell how much I hate that!!! ;-) Users are too creative. Some will merge some cells and not others and boom the file can't be properly sorted anymore. Many will use font color, font weight or background color to mean wildly different things, which is very difficult or impossible to sort or do a sumif over. Others will add footnotes, because why not?, and links to spreadsheets that never leave their own device, or mini-blank-rows for spacing and general layout, etc. It's completely insane.
> I think big data files should be handled in a db rather than in a spreadsheet.
Your side lost completely. Pop a signal flare or build a bonfire, maybe someone can rescue you from the island you've been living on since the war ended.
If Microsoft had adopted this attitude, then by now Excel's market share would probably be 0% and Google Sheets' would be 100%. Microsoft doesn't add features because they like bloated software; they add features because the market demands them, and the market demanded support for more than 65,535 rows.
It works fine if the user is ok with the features from 2003. E.g. Excel 2003 is limited to smaller spreadsheets of 65536 rows by 256 columns but Excel 2007+ can handle larger worksheets of 1048576 rows by 16384 cols.
I also recently used Excel's new LAMBDA() function which was introduced 2020. In earlier versions, it required writing a VBA UDF to accomplish the same task of assigning a temp variable with a ephemeral value to calculate on intermediate values. VBA is a workaround but LAMBDA() is nicer to use because Excel will throw up scary security warnings whenever the xls file containing VBA macros is opened.
I might be able to get by with Word 2003 more than Excel 2003.