I see alot of business use excel as a way to not engage with IT teams since they can get very far without building true systems for the their needs. So I am not sure if this is a feature that will lead to further entrenching of excel into non-enterprise applications or will enable teams to more easily disconnect from excel as the tool to do all things. I guess time will tell.
Might be unpopular opinion: Excel is best with no frills and just does what it does best- simple, quick and stable.
Power BI can continue to have whatever enhancements MS wants to push.
I'd venture out and guess that Excel is probably the most widely used programming environment in the world. Excel macros are a type of programming language, and there are many businesses that rely on complex Excel spreadsheets as part of their operations.
The fact that these are called macros and not a programming language might be a reason why they are so heavily adopted: to avoid scaring people away from using Excel. This reminds me of an observation from Richard Stallman's speech about Emacs (https://www.gnu.org/gnu/rms-lisp.html), where secretaries used Emacs Lisp to extend the editor.
In a personal computing world that has a sharp distinction between "user" and "programmer," Excel is one of those exceptions where the distinction between "user" and "programmer" is blurred, since you need to use macros to take advantage of Excel's power. Excel macros are the gateway to learning Visual Basic for Applications, a full-fledged embedded programming language. Then once you know VBA, then the road to learning other programming languages such as JavaScript and Python becomes easier.
because sometimes I need to deploy things that will fail gracefully with people who don't know how to code. I can setup some complex things in excel that if some one does somethign unexpected or data does something unexpected, they can just overwrite things.
Code is great but requires systems that are not always in place.
I would argue a formula one race car is better than a 10 year old honda. But the honda doesn't need a support crew to get me to work, can be started in an instant, and doesn't care if I forget to change the oil for a year.
context matters in choosing technical solutions. Your argument is no different than all those other ones over what programming language is 'best'
It's a reactive functional programming IDE, that existed way before the term RFP was popular.
I'm serious. It's functional, as you say, and cells form a dependency DAG which drives their auto-update, which qualifies it for the "reactive" adjective.
The analysts I knew at my last job would use Excel to prototype huge, incredibly complex business logic and calculations, and then have programmers (or the skilled ones would do it themselves) implement this stuff in SQL or whatever language made the most sense when it came to analysing billions of rows of real data.
It's an exceptionally powerful tool for prototyping.
Absolutely, if you're generating any kind of ad-hoc reports for biz/marketing folks it is often a much better to implement it in a way that they understand and update than to write your own code to produce it.
"Paste the export from {business system} in this tab, then drag down column F in the first tab to update the vlookups." Boom, no more 5-minutes-before-the-board-meeting-can-you-just-rerun-this-report-with-different-parameters emergencies. For the most part.
I think almost the opposite. Excel is useful for quick exploration or entry of data. If I need data entry from many people, a web spreadsheet can be useful, too.
At the point that others will be dependent on the output, I want version control and tests. You can make that happen with excel but it's not easy.
I use Excel all the time, and I absolutely code. But I agree with your opinion here - Excel was (and to a certain extent still is) a major engine for Microsoft’s growth.
In what? Excel has versatile uses, it can be used for both analytics and analysis of data.
You can make dashboards, pivotcharts, etc. in excel in minutes when doing the equivalent will take you hours, if not days, to code from scratch.
I'm not sure where you get the idea it's only for "those who can't code". In my domain, mining, there are many, many excel sheets for all sorts of things that would never merit a single line of code being written. We're far from the only. Sure, at a certain scale and below that for certain types of projects, switching to code and databases make sense. Other than that, it's just plain smart to use the labour saving tool that is Excel.
I dont even see it as an opinion. I consider it as a fact.
There are possibly trillions dollar worth of revenue around the world relying on Excel. And one reason why other office software couldn't match MS Office. Even if you promise 99% compatibility with Excel, no one wants to risk 1% of messing it up just to save a small amount of money on MS Office. Especially when MS now offer it as subscription which fits most business P&L better than a one off purchase.
And that is a reason why I see a small possibility of MS one day open sourcing parts of Windows.
Unfortunately Excel on Mac isn't as smooth / performant as Excel on Windows.
Excel makes a good user interface for quick scientific apps... it used and extended a fairly complex radiometric analysis program at NASA/JPL that was built in Excel and used VB scripts for most of the calculations.
I made the same app in both Matlab and Python/Qt and it took far more time in both of those than it did in Excel.
Time is money...
From a sloppy reading of the headline I first thought this was some way of making Excel (optionally) typed, sort of like moving from JavaScript to TypeScript.
I wonder if this could work? It's an interesting idea, I think. I'm sure there have been attempts in the past...
I guess you would be able to assign both normal units and compound units to cells (like m and m/s^2) as "formatting" and do type checking when editing a cell that references other cells.
This is exactly what I thought. The things it's bringing in don't seem like "types", they seem like "rich structured data objects, usually imported from the web, that live in cells on sheets so you can refer to in formulas".
I wanted cells to have types -- not just dimensions like meters and volts but arbitrary composeable tags with a tag arithmetic, so that you can make it impossible to (or at least easy to notice when you) add "daily active users" and "monthly active users".
I read a thread here on HN just a couple days ago about people whose job it is to pore through spreadsheets that drive trillions of dollars for companies and find logical errors (like the above nonsensical addition of two numbers that don't make sense), and that they save companies hundreds of millions by preventing mistakes in planning etc.
Maybe I'm missing the point, but compared to real types, who cares about bringing a rich structured data object describing hydrogen into a spreadsheet?
They'll probably replace it JS, seeming as that seems to be the way forward for Office and SharePoint Add-ins, or at least it was the last time I ever looked at that stuff.
A snarky follow-up question I have is, will the standard way to work around date confusion be to have all values in CSV wrapped in { ... }, or some other delimiter, to have Excel automatically convert it into structured objects which presumably won't be doing date autoguessing?
The stupidest part is where it is localized so in some parts of the world the comma is the decimal separator, yet it also is the field separator. So then there’s a different field separator but there is no way to reliably detect that.
CSV is full of stupid things like that. Full of magic, underspecified hacks and useless nonfeatures.
Periodically I find myself needing to play with some data in a lot of different ways and potentially share that data in a professional context where appearance matters. It is during those periods I start looking up all of the excel functions and features.
However, if I am only occasionally looking at data and/or repeating the same operations than code + csv (or database) makes a lot more sense and gives me flexibility to deal with edge cases. I still end up opening it in excel but mostly because I already have it installed.
To be honest, I would sort of like a more primitive fast csv data viewer for times when I am feeling rusty on excel and bullish on small scripts. When you are doing the data manipulation elsewhere excel is overkill.
46 comments
[ 2.6 ms ] story [ 92.7 ms ] threadThe fact that these are called macros and not a programming language might be a reason why they are so heavily adopted: to avoid scaring people away from using Excel. This reminds me of an observation from Richard Stallman's speech about Emacs (https://www.gnu.org/gnu/rms-lisp.html), where secretaries used Emacs Lisp to extend the editor.
In a personal computing world that has a sharp distinction between "user" and "programmer," Excel is one of those exceptions where the distinction between "user" and "programmer" is blurred, since you need to use macros to take advantage of Excel's power. Excel macros are the gateway to learning Visual Basic for Applications, a full-fledged embedded programming language. Then once you know VBA, then the road to learning other programming languages such as JavaScript and Python becomes easier.
Code is great but requires systems that are not always in place.
I would argue a formula one race car is better than a 10 year old honda. But the honda doesn't need a support crew to get me to work, can be started in an instant, and doesn't care if I forget to change the oil for a year.
context matters in choosing technical solutions. Your argument is no different than all those other ones over what programming language is 'best'
Excel IS a programming language.
I'm serious. It's functional, as you say, and cells form a dependency DAG which drives their auto-update, which qualifies it for the "reactive" adjective.
It's an exceptionally powerful tool for prototyping.
In excel the ability to be sloppy is actually really nice to just sling together a few random models and call it good when I don't need to be precise.
It is the best of breed on the category by far.
But yes, only used by those who can't code.
"Paste the export from {business system} in this tab, then drag down column F in the first tab to update the vlookups." Boom, no more 5-minutes-before-the-board-meeting-can-you-just-rerun-this-report-with-different-parameters emergencies. For the most part.
At the point that others will be dependent on the output, I want version control and tests. You can make that happen with excel but it's not easy.
> It is the best of breed on the category by far.
But would it have been if MS hadn’t controlled the playing field for WordStar, Lotus 1-2-3, etc.?
In what? Excel has versatile uses, it can be used for both analytics and analysis of data. You can make dashboards, pivotcharts, etc. in excel in minutes when doing the equivalent will take you hours, if not days, to code from scratch.
There are possibly trillions dollar worth of revenue around the world relying on Excel. And one reason why other office software couldn't match MS Office. Even if you promise 99% compatibility with Excel, no one wants to risk 1% of messing it up just to save a small amount of money on MS Office. Especially when MS now offer it as subscription which fits most business P&L better than a one off purchase.
And that is a reason why I see a small possibility of MS one day open sourcing parts of Windows.
Unfortunately Excel on Mac isn't as smooth / performant as Excel on Windows.
I made the same app in both Matlab and Python/Qt and it took far more time in both of those than it did in Excel. Time is money...
I wonder if this could work? It's an interesting idea, I think. I'm sure there have been attempts in the past...
I guess you would be able to assign both normal units and compound units to cells (like m and m/s^2) as "formatting" and do type checking when editing a cell that references other cells.
I wanted cells to have types -- not just dimensions like meters and volts but arbitrary composeable tags with a tag arithmetic, so that you can make it impossible to (or at least easy to notice when you) add "daily active users" and "monthly active users".
I read a thread here on HN just a couple days ago about people whose job it is to pore through spreadsheets that drive trillions of dollars for companies and find logical errors (like the above nonsensical addition of two numbers that don't make sense), and that they save companies hundreds of millions by preventing mistakes in planning etc.
Maybe I'm missing the point, but compared to real types, who cares about bringing a rich structured data object describing hydrogen into a spreadsheet?
CSV is full of stupid things like that. Full of magic, underspecified hacks and useless nonfeatures.
https://www.youtube.com/watch?v=ICp2-EUKQAI
However, if I am only occasionally looking at data and/or repeating the same operations than code + csv (or database) makes a lot more sense and gives me flexibility to deal with edge cases. I still end up opening it in excel but mostly because I already have it installed.
To be honest, I would sort of like a more primitive fast csv data viewer for times when I am feeling rusty on excel and bullish on small scripts. When you are doing the data manipulation elsewhere excel is overkill.
But every now and then it is a lifesaver