Advancing Excel as a programming language [audio]
blubrry.com
blubrry.com
When it comes to data analytics IDEs there is a fundamental tradeoff between staring at the data or staring at the transformations. Excel makes sure you are brutally aware of each edit you make to your data at the expense of reproducibility and auditability of your transformations. Python takes the opposite end of the trade -- obscuring the underlying data, but bringing the transformations to the forefront. For non-programmers trying to learn Python (especially for data analytics), the biggest hurdle is losing touch with their data.
I've been building a Python package, Mito (https://trymito.io/hnc), to try to address this tradeoff for those who want to analyze data with the intuitiveness and data-first-ness of a spreadsheet, but with the power and traceability of Python. Mito is a Jupyter Lab extension which gives users an interactive spreadsheet that automatically converts your spreadsheet analysis to the equivalent pandas code. You can write Excel formulas, merge datasets, create pivot tables, etc.
The reason I say that is I think the major pain point in its hypothetical widespread adoption would be getting users accustomed to the ergonomics of accessing attributes in a programming language when they only understand noob-friendly Excel formulas, which is more functional in nature.
Looking at the demo, I think some pseudo-code such as the following could be easier for e.g. an office worker than pure python:
ADDCOLUMN(Sheet='Train Stations', Name='Accepts Bags') # defaults to appending at the end
SETFORMULA(Column='Train Stations'!'Accepts Bags', As=IF('Train Stations'!'Checked Baggage' = "Y", 1, 0))
PIVOT(From='Train Stations', To='Pivot', Keys=('State'), Values=('Accepts Bags'), Formula=SUM)
SORT(Target='Pivot', By='Accepts Bags', Direction='Asc', NA='Hide') # defaults to ascending, NA first
Clearly, it's not like I've thought this through carefully and am not claiming this particular example is really ergonomic, but hopefully this illustrates the point I'm trying to make.It would not need to look like Excel, but I think the jump from spreadsheet -> Python may be a step too far for the average user than, say, spreadsheet -> some functional approach.
It seems like what your proposing is almost a wrapper around pandas functionality to make the language easier to read for Excel users. I think that's a super interesting approach which we honestly haven't thought that much about. As a rule of thumb for Mito right now, any spreadsheet formula gets generated as a Mito formula (ie: using an IF statement in the Mito spreadsheet generates the code IF(A > B, 1, 0) instead of the Pandas code) and anything else is raw pandas code (ie: pivot tables, merges, add column).
In general, we've been thinking about trying to move more of the code to the raw python approach since we've heard things like "not seeing the raw script makes the code unproductionizable" etc. But I also see your point that beginning Python users might prefer readable code over Python code. If we took that approach, users would still get the reproducibility, auditability, and ability to use a spreadsheet interface on large datasets, they'd just sacrifice any semblance of learning Python. That's great food for thought!
You are correct. It's a combination of REPL like behaviour and being able to see the entire state at once that does it. Excel is the most agile programming environment known to man.
That is an interesting point regarding Excel vs Python. But no-code, flow-based data transformation tools such as Easy Data Transform (my own product), Alteryx and Tableau Prep offer a different approach, by having a canvas of transformations and allowing you to see the data after each transformation with a click. This loses some of the massive flexibility of Excel, but also has a lot of advantages, including: no syntax to remember and the transformations are much more visible and easy to reverse.
I'm a consultant and at every client (mostly public sector) I discover new ways of solving problems with Excel which would otherwise not get solved because the blockers to buying "the right tool" are simply too great.
At my latest client I've plotted their data on a map by colouring in cells as pixels using custom formatting and zooming right out so it isn't too blocky. It's too hard to get access to GIS software even though other departments in the same organisation have it.
I've been relatively fortunate in my public sector experience: Management have allowed me to use tools other than Excel.
But also, thinking about this a bit more, doesn't excel have the ability to plot geographic data?
I believe you, but isn't it baffling that your superiors couldn't recognize that giving you access to some Python or whatever would vastly improve your productivity, what you produce, and your happiness, all for a grant total of €0 and some de-rigidifying of arbitrary rules?
#mode13h
Like all such bespoke creations, it worked fine, and then the only guy who understood it left.
Some see a problem: "Don't use Excel"
I see an opportunity: "Evolve Excel so it's fit for this purpose".
It took me a whole 5 seconds to google [1] up. As far as I can remember Anaconda can be installed without admin permissions on any PC and pulling the needed packages is a matter of minutes. Or a Tableau Online account with Tableau Creator desktop app having similar GIS functionality costs a whole 70 bucks a month, OMG. The public sector seems to excel in making up "blockers" to justify why shit doesn't get done.
[1]: https://blog.jupyter.org/interactive-gis-in-jupyter-with-ipy...
And yes they make up lots of shit. I don’t. I just make the best of a bad situation for people who need to get shit done despite the stupid policies.
> I'm a consultant and at every client (mostly public sector) I discover new ways of solving problems with Excel which would otherwise not get solved because the blockers to buying "the right tool" are simply too great.
I just don't get this. Most of the tasks where I've seen incredibly creative/perverse Excel gymnastics used in real life could have been solved far better with a bit of Python (or whatever). What "tools need to be bought" in the vast majority of cases?
Lambda: The Ultimate Excel Worksheet Function - https://news.ycombinator.com/item?id=26900419 - April 2021 (109 comments)
Xkcd: Excel Lambda - https://news.ycombinator.com/item?id=26899793 - April 2021 (1 comment)
Lambda: The Excel Worksheet Function - https://news.ycombinator.com/item?id=25990978 - Feb 2021 (1 comment)
Lambda: The ultimate Excel worksheet function - https://news.ycombinator.com/item?id=25923628 - Jan 2021 (4 comments)
Lambda: Turn Excel formulas into custom functions - https://news.ycombinator.com/item?id=25318386 - Dec 2020 (135 comments)
Announcing LAMBDA: Turn Excel formulas into custom functions - https://news.ycombinator.com/item?id=25312725 - Dec 2020 (1 comment)
Microsoft introduces LAMBDA functions for Excel - https://news.ycombinator.com/item?id=25295120 - Dec 2020 (7 comments)
https://github.com/htruong/leetcode-excel
I got bored after a while and didn't try to solve more problems.
Here is a fun thought: Excel has potentials in teaching non-programmers to think about algorithms. Translating a problem or a function from Excel to a programming language has the potential to break the ice for people who just "can't write a program."
At this point they can just as wel get rid of the different GUIs facade and instead implement some contextual interaction model (and hopefully they'll include an API so we can generate these documents programatically and don't have to deal with this nth clippy generation :) )
An official solution would be nice though. These open source projects are popular enough to warrant one I'd say!
Yes, there absolutely is.
You can create a document with styled text in Excel instead of Word, just as you can edit a photo in Paint instead of Photoshop. You can do it, but the two tools have dramatically different capabilities.
It's important to think about developing for use-cases otherwise we will end up with overly complex software that aims to be all-things to all-people.
This is exactly what I believe the current state of the MS Office applications to be.
The interface and/or implementation isn't always ideal for the purpose you would generally use a specific app for, but the functionality is there.
> dramatically different capabilities
Embedding a fully functional Excel spreadsheet is only a few clicks through the ribbon and some frustration away in Outlook, Word, and even PowerPoint.
This is effectively opening a reduced version of excel in a very limited way, primarily for embedding one document in another and allowing limited editing. You don’t get the full functionality of the other application.
I can see why I would want to change the axis on a graph even after I have pasted it into my email, but why would I want one app to be both my spreadsheet and my email inbox?
Are you a user of office suite? I spend about 70% of my work life between excel, PowerPoint and Word and have never once wanted them to be one app, but quite often have wanted better integration.
In regards to PowerPoint, I imagine it lags pretty far behind in usage compared to both Excel and Word. Not many people are making presentations in the grand scheme of things. My intuition says that it's mostly upper management and maybe a single person in a group using PowerPoint "often".
Notes are usually smaller with simpler structure and formatting. With notes, it helps of the app gives you a way to organize the notes. This is really a different use case.
I’ll go for latex if something has to be published and certainly use power point a bit but am always on the lookout for new approaches. It’s great that power point can pull/receive graph data.
Probably the worst example I've seen first-hand was an entire retail banking loan-approval process running off of a single, shared, gigantic spreadsheet, that hundreds had tinkered with, but no-one understood or took responsibility for, and where the accompanying Word document of "things not to do" was bigger than the workbook.
Even yesterday, a friend of mine discovered they'd underclaimed expenses for a total >$1,000 due to a dodgy spreadsheet. Something as simple as pasting a list of dollar amounts from a webpage into Excel can produce an incorrect SUM() if/when trailing spaces creep in, since the resulting values may be treated as strings and evaluate to zero - and so it had transpired. Not even "text to columns" could fix it; you have to a) know about this lurking monster, b) use formatting to make it casually evident, and c) use Replace to strip the whitespace. What a crock.
But is that really the right comparison? Lots of people just don't have the skills or time to build a specific applications. Without Excel, what would they do? There are some places where a 90% solution is worse than no solution at all (at least no solution is a forcing function for a "real" application), and in many ways Excel isn't the best expression of the _idea_ of an Excel-like, low-barrier-to-entry declarative programming environment with a built-in UI, but it's truly a wonderful tool. It makes a lot of automation possible for a lot of people.
There's some real doozies out there. The Reinhart-Rogoff error, which was used to justify imposing austerity on Greece [0]. The UK's COVID tracing fiasco [1]. The list goes on. People using Excel have no business making decisions that affect other people's lives.
[0] https://stanfordreview.org/clarifying-the-implications-of-th...
Also - 15 digit NUMBER precision leading to truncated values that you only discover when it's too late; no Macro undo; no way I'm aware of to transform columns/rows from formulas to their values without intermediate cut/paste steps; lots of essential features (like "Copy only visible range containing hidden cells") buried in Find & Select > Go To Special menu without keyboard shortcuts; Excel's magic ability to change cell data types by merely touching a CSV (open/closing without saving changes)...
And often the easiest way to try a few things and communicate the idea is by prototyping it with a spreadsheet.
To add to you list, back in the 80s, I wrote a simple x86 assembler, and a simple neural net, in Lotus 123.
Whilst I agree with the general sentiment of Excel's ubiquity, I'd argue that Email is in fact the most used piece of business software.
I use spreadsheets but oftentimes they are not the right tool for the job.
Ok then, we had a go, and it was actually quite fun coming up with a scheme for getting calculations to propagate successfully and without getting locked into infinite loops; inevitably though the result was a very poor man's copy of what Excel can actually do.
So we went back and said look, far and away the best way to do this is to either use Excel itself, or embed it, whereupon the actual reason for their aversion to Excel came out: they had had cases, they explained, where project managers had used white ink in white cells to hide data and thereby forge financial calculations to their benefit, and they just wanted to prevent that from happening! I wanted to politely suggest that they solve their "technical" problem by getting more honest employees, but in any case the project got canned shortly thereafter.
Innovation by (and beyond) the numbers: A history of research collaborations in Excel
https://www.microsoft.com/en-us/research/blog/innovation-by-...
https://www.microsoft.com/en-us/research/podcast/advancing-e...
Is it technically difficult?
You can do it via .NET, but a lot of people prefer VBA for its "quick and dirty"-ness.
As a demonstration, I ran a ray tracing python script from Calc and it rendered to cells in the spreadsheet.
I think they still have several Python libraries out there, but yeah I wish Excel included Python support along with VBA.
What? Am I the only one who hates VBA with a burning hatred of a thousand suns?
The object model and IDE are a big part of it though, maybe even more so than syntax horrors like while..wend vs do while..loop.
You are right that you can use something like C# to manipulate Excel files, but there isn't a ton of tutorials on it, which makes it difficult and prohibitive to learn.
I think Microsoft is making JS a first-class scripting language for Excel (and slowly deprecating VBA).
I've never used it myself, but I have tried to use the Excel JS API, and it was quite a pain.
I think part of the problem is that any scripting language rolled directly into Excel will be expected to keep backwards compatibility. Microsoft doesn't have full control over Python/JS, and they would like to avoid issues such as the changeover from Python 2 to 3.
Microsoft could implement its own fork of those languages, but is that what customers actually want?
The difference is that add-ins is installed at the application level instead of the spreadsheet level (like VBA macros).
This is the way the world ends
Not with a bang but a #VALUE!
— T.S. Eliot, The Hollow Men (1925)In regards to having JS/Python scripting it, if you using Postgres, just add v8 or python plugin, and there you have your advance excel programming in the language of your choice.
Makes sense to do it from inside Excel no?