Some things in Excel have not improved since 2003, that should be fixed before toying with "AI" . For example, when importing a CSV:
- Excel cannot guess the encoding of the file, and relies on the user selecting it from a list that has maybe a hundred values (?!); the most common encoding, UTF-8, is neither at the top or at the bottom of that list, but somewhere near the end, and is called "65001 : Unicode (UTF-8)" (the preceding value is "65000 : Unicode (UTF-7)"). There is little chance non-technical users will get this right the first time, or any time thereafter, and the result is files that are circulated with garbled encoding and wrong values.
- Excel cannot guess the separators either! (How hard can it be?)
That's probably the reason why one cannot "open" a CSV file directly in Excel and having it displayed properly; one has to go through the whole "import" process. Yet Windows insists all CSVs should automatically open in Excel.
Yes, it's a minor thing, but it should be so easy to fix; instead of that, recent versions of Office have brought incredibly annoying animations that take 2-3 screens to disable.
> That's probably the reason why one cannot "open" a CSV file directly in Excel and having it displayed properly; one has to go through the whole "import" process. Yet Windows insists all CSVs should automatically open in Excel.
Both of these things are consistent with trying to keep users in Excel. Make it easy to accidentally open Excel, but don’t make it too convenient to use open data formats when you have a proprietary one.
Maybe... but I wouldn't be so quick as to assume bad intent ("never attribute to malice", etc.)
What's the deal with "copy" for example? Why does the source of the copy have to be highlighted, why is it so fragile, why does it disappear from the clipboard when one presses the Escape key? This has been the case since I think the very first version of Excel, and never changed.
I don't know of any other program that works that way. It didn't make sense then (I think), and it doesn't make sense now.
The OOXML format is heavily oriented around internal details of Office in ways that makes it pretty inconvenient to work with even if it's "open". Also IIRC some more esoteric parts are just binary blobs that aren't actually documented and the specifications just say to do what Office does.
I have an even better one for you — if the language/region of your system is different, Excel parses the file differently. My example, Slovak region, numbers are officially written with a comma — 1,3 meaning a decimal "one point three". When you open a file that has the numbers from a different region (so 1.3), it completely falls apart.
Workaround for anyone struggling with this: Use the Import feature from the Files menu instead of the usual Open dialog for csv files. You can change decimal separators in the import wizard.
This is one of those things that make absolutely no sense. The "."/"," difference should only apply to displaying numbers to users like any other localization related change. Why on earth is it writing numbers differently in a standard format meant to be read only by computers? Such a colossal fuckup making csv files always broken for half of Excel users.
Excel cannot guess the separators either! (How hard can it be?)
What is the separator in this .csv file ;)
1,2;3,4;5,6
But on a more serious note, I completely agree. There are so many small quality of life things that can and should be fixed in Excel, and it's baffling that they haven't.
Sure, there are some edge cases where guessing the separator would be hard, but in 99% of cases you can correctly identify the separator pretty easily and in case you can't you just don't pre-fill that field in the import dialog.
Someone should tell the Excel developers, because they obviously didn't get that message. They use the .csv extension even when exporting files with ; separator.
How about a diff tool to track changes in excel DATA, FORMULAS, and MACROS. Do you know how many business are run with handcrafted excel sheets that are not in source control?
Those .xlsx files aren't just blobs. They're ZIP files. If you want version control for Office documents, it's as easy as unzipping them and checking in the results.
It seems like they don't want to change anything that affects existing behavior, so they're mostly adding new features that are orthogonal to existing features.
Unfortunately this means that they're not really fixing most of the annoyances that were already present.
"Excel Labs" appears to just be an add-on using the normal API which is a lot easier than making change to Excel itself.
They've also added stuff like new functions for formulas and a new type of comments that are more like word comments (while renaming the old comments to "note") but it's pretty clear that they have chosen to focus on things that they can tack on without having to change existing functionality (presumably either so they won't break anything and/or because it's simpler easier to add this kind of stuff rather than getting too deep into the existing codebase)
I mostly agree with you. But I assume dynamic-array formulas (released in 2018) required deep calculation-engine changes. (For me, this feature is a game-changer.)
Excel has some annoying defaults when importing data, too.
My company tracks transactions with an ID that is a numeric string that Excel assumes is an integer but longer than it supports so it truncates the value and displays it in scientific notation.
Original value: -7223371999747962216
Truncated value: -7223371999747960000
Displayed value: -7.22337E+18
It would be fine if it just treated it as text but by discarding digits it makes the values useless. You can’t open a CSV file directly. You have to manually import the data and specify specific columns as text. Every. Single. Time. It cannot be automated.
I’ve been sent so many excel files with truncated data like that because most people don’t even know about the problem, let alone know how to work around it.
Sure, if you have control over the source, but that is not always the case. CSV is very loosely specified and there are large variations in implementations.
I think you may slightly misunderstand the functionality, it's an updateable link to some other file (which is, frankly, great). I can import a CSV file I generate with code ONCE, build up a huge calculation from it (probably in other sheets), and then the next day, regenerate the CSV, update the link WITHIN EXCEL, and boom, all of my computation is redone.
Very underutilized feature, but incredibly useful when using Excel not as a CSV viewer (if you want that, you can buy that elsewhere) but as a critical part of running a business.
Excel exists to make it almost free to write accounting-like software. It does NOT exist to view CSV files.
I've opened thousands of CSV files directly in Excel and never had one not open correctly (unless the file itself was not valid CSV, especially with things not quote-enclosed properly).
It's likely I've mostly had to deal with ASCII / Latin alphabet, so don't know how well it handles unicode.
I open csv files in excel every day without going through these dialogs. Aside from excel doing stupid stuff like misinterpreting columns as dates every once in a while, it’s good enough to eyeball stuff.
There’s something unbeatable about the purity of a spreadsheet. For certain kinds of problem, it’s one of the most understandable ways to communicate a program.
But there are the obvious problems, as formulas get inscrutable and you really want some more powerful data types.
So I’ve been playing with the new Excel features - lambdas and the new kind of array formulas. And they’re kind of great! I ported some non-trivial analysis algorithms from numpy to excel and it makes for a highly shareable and havkable programming environment for non-coders.
There’s all sorts of crazy excel warts (I’m doing maths with complex numbers, and the handling of those is a true “WAT”)
It’s kind of almost-great. I can’t put my finger on it but I feel like it’s close to a really winning programming environment for certain kinds of algorithms-transforming-data programs. I think Excel probably has too much baggage to get there, but these experiments are still really interesting.
It is a grey area, spreadsheets are great but at some point you are building a mammoth with it. I also find Excel, and Google Sheets outdated on its own "form-factor".
It would be great to hear from the HN community about ways to improve spreadsheets. For example, adding new types and easier integrations with other systems. Also having views/forms. Lotus Notes was revolutionary in this aspect. Excel is the measure because they have a good engine. Probably we need to create a great DAG engine and put the spreadsheet over it.
> It would be great to hear from the HN community about ways to improve spreadsheets.
I’m working on this! Very early days so far, and I have nothing much to show for it yet, but I do have some ideas on integrating static type inference and proper data structures into spreadsheets. My initial prototype is at [0]: it’s horrifically buggy in just about every way (don’t even try to get it working!), but the screenshot should give some idea of what I’m thinking should be possible.
The tables are sqlite tables, so the schema has to be rigid, while I think they also offer views that allow you to make more user-friendly views. They also let you run Python inside the formula
> Probably we need to create a great DAG engine and put the spreadsheet over it.
Why a DAG? You might want recursion. We have pretty great computational models already, I think that what you're talking about is an interface into such a model (a statically typed language) through a spreadsheet like interface, which isn't totally revolutionary.
The problem is making something that can unseat a behemoth like Excel. The only things that seem to have made a dent are Sheets (on price) and services that unbundle Excel into no-code/low-code products where you make your money by not being as powerful.
Thats 10 years old! I remember that story. Working in this space I have seen a lot of excel 'systems' get replaced with what we would qualify as proper applications (with all the overhead that comes with that). Of course, traders will miss the nimble nature of being able to update the pricing models themselves instead of having to put a ticket in, but it's prevented a magnitude of other blow-ups that have happened somewhere in the multiverse.
Yes Excel lately is turning into a really compelling product, using functions such as sequence (dynamic arrays), lambda (pure functions) and let (defining sub-variables). You'd think you're coding in a pure functional language, and that's great! Now, ff only Excel had a convolution function! But nonetheless it's a great GUI, everybody knows how to use it and sharing it is dead simple.
The one downside I can find is the lack of a good plotting library. And yes comments as well is something I miss a lot.
Most of us who use Excel are still using it as though it were 2013. Are there any good tutorials about the major features, like lambdas and dynamic arrays, that have been introduced in the last few years?
Oh, I need to check that out. The universal language and portability of a spreadsheet is really hard to beat.
Seeing how people often read xls-sheets by backtracking formulas, it would be great if MS could add support for comments within formulas (multiline formulas being a thing for many years now)
That wouldn't blow up the whole complexity of formulas, but still allow at least to explain some of these huge formulas people have to deal with on a daily basis.
As a hack workaround, I drop everything into a `let` block and define "variables" named "comment1", "comment2", etc that are just comment strings and otherwise unused. It affects performance if you're hitting that formula a lot with disparate data, but most of the time anything needing performance from a cell should be using the new arrays processing anyway.
Portable in the sense of sharing something across different departments of a company, universal in the sense of a tool that can be understood and used across many disciplines of work.
- Excel cannot guess the encoding of the file, and relies on the user selecting it from a list that has maybe a hundred values (?!); the most common encoding, UTF-8, is neither at the top or at the bottom of that list, but somewhere near the end, and is called "65001 : Unicode (UTF-8)" (the preceding value is "65000 : Unicode (UTF-7)"). There is little chance non-technical users will get this right the first time, or any time thereafter, and the result is files that are circulated with garbled encoding and wrong values.
- Excel cannot guess the separators either! (How hard can it be?)
That's probably the reason why one cannot "open" a CSV file directly in Excel and having it displayed properly; one has to go through the whole "import" process. Yet Windows insists all CSVs should automatically open in Excel.
Yes, it's a minor thing, but it should be so easy to fix; instead of that, recent versions of Office have brought incredibly annoying animations that take 2-3 screens to disable.