Wouldn't actually using Excel create less friction for potential users?
Your target audience is theoretically Excel users who want/need to code instead, but I think you're alienating the power users of Excel, because their power tools are unavailable in the Mito spreadsheet editor.
For example, have you considered dumping the dataframes to "smart" xlsx files with backing code that connects to a local server, listens to worksheet events and tells the server everything that happens so it can write python code in the source notebook?
We've thought a lot about this one. It's a good idea for usability - agree with you there - but there are some development complexities that make it hard for other reasons.
We spent a considerable amount of time two years ago developing Excel extensions for our spreadsheet-version-control product. It was... not ideal from a development perspective.
The benefits of being in Excel (it has all the features!) is also the cost of being in Excel (you have to support all the features!). This means v1 of the extension you describe with either have to be non-functional on most of these power tools you mention, or we'd need to spent years building in stealth mode before launching something fully working (and I'm not even sure we ever could get there... Excel is... literally so big).
Also, the actual extension points for Excel are not as fully-featured as you might think! In practice, we'd likely have to gate much of Excel's functionality to get an extension that actually works -- there are some hard limits to what you can extend, further making it really hard to actually support these power tools in practice.
Also, for the sake of our users, we love being in a Python development environment! In practice, many of our users move really fluidly back and forth between writing Python and editing a Mito spreadsheet. Effectively - bring a spreadsheet in for what it's good at, when you want it.
We'll keep considering this one, though -- I have a _feeling_ Microsoft might make some Python moves in Excel the next few years... :)
> We spent a considerable amount of time two years ago developing Excel extensions for our spreadsheet-version-control product. It was... not ideal from a development perspective.
So here’s the thing. You develop once, people use many.
So the point of dev is to do the not ideal things so the many users don’t have to. Suck it up so users have it easy. Software that doesn’t make users change, that doesn’t get in the way of a career of learning to bend Excel to their will, they’ll throw money at you for that.
I could have been more clear with my language -- "not ideal" doesn't mean that it was unpleasant (actually not awful hot-reload loop).
It was more-so that it's technical infeasible, given with Excel exposes to you as an extension developer. Aka, the gates the add to their ecosystem make it pretty much impossible, which is another one of the reasons we're open source!
Will clarify my language around this going forward!
Excel workflows are terrible though. No version control, hard to test, prone to indexing errors. And doing very sophisticated things with it gets hard; lots of financial analysts/quants are moving over to Python for analysis anyway.
If you’re thinking about this in isolation, I can see why it would seem a bad idea to move power-excel users to Python. But take this in the context of a much wider shift where many shops are already shifting to Python for other reasons, and so we need a way to help transition the Excel power users over too.
Excel has its place for sure, but I think it’s interesting to consider whether another tool paradigm could gradually replace it; we would need to really hone the flexibility and expressivity of the UI for simple tasks. The benefit would be that when your task grows you don’t need to re-implement it in a new Python engine.
+1, beyond the most obvious reasons that companies are moving away from Excel (too much data to process, not enough robust automation features), there are important workflow management reasons that companies are making the transition.
More and more, we're hearing that companies want to use software engineering practices on their data analytics workflows -- things like version control, easily understanding what edits are applied by looking at the code, and even things like CI to automatically build dashboards from the most up to date data.
While you technically could build tooling around Excel to do a lot of these things, its much easier and already exists in the Python ecosystem.
Your target audience is theoretically Excel users who want/need to code instead, but I think you're alienating the power users of Excel, because their power tools are unavailable in the Mito spreadsheet editor.
For example, have you considered dumping the dataframes to "smart" xlsx files with backing code that connects to a local server, listens to worksheet events and tells the server everything that happens so it can write python code in the source notebook?