It runs on an very inexpensive VPS. There's no VCs or anything with this and since all processing happens on the users device, my costs won't really change at all.
Still figuring out potential monetization. Is there anything you'd pay for?
Interesting - why do you say it would be nice if the posted stated that it was an affiliate link? Do you feel it takes away an option from you or reduces the link's value?
It reduces the link value to me since now the poster is financially motivated to post it. So do I trust that it really is a good product or is the poster just posting an affiliate link so that they can earn money or is it somewhere in-between.
Everyone who you see posting tweets longer 280 characters is paying for the premium subscription, which leads me to believe X might actually be more successful (more sustainable?) than old Twitter in terms of monetization.
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.
Applause for the effort but I doubt that this will become popular. Music notation has been a certain way for hundreds of years for musicians around the world – a notation with the universal legibility of mathematics.
However, as someone who sight-reads all of his piano music, I'd be interested in experiencing if this makes sight-reading any easier or harder. It's taken many years of experience to be able to spot and predict patterns several measures ahead of where I'm playing, and I wonder if future musicians could get to advanced sight-reading levels more quickly using an alternative notation.
>Applause for the effort but I doubt that this will become popular. Music notation has been a certain way for hundreds of years for musicians around the world – a notation with the universal legibility of mathematics.
This system is really compatible with the standard one though? It's essentially a visual skin.
Removing the middle line is kinda nice - I remember as a kid having trouble and counting lines a lot to figure out what not something was.
The sharp/flat notation seems pretty week though/visually unclear?
I'm not sold on the the numbers in the clef symbols - I don't find it so helpful, and don't have a very intuitive sense of what the number of the octaves are. Especially because the rest of the notation is quite visual/geometric, it's odd to see it resorting to adding numbers here (where the normal notation leaves them out unless the clefs are in non-standard octaves).
The current piano layout (seven white keys and five black keys) is pretty closely tied to traditional music notation (sharps and flats => black keys), so I'd guess sight-reading with this notation would be harder on current pianos.
In principle you could imagine a more regular piano layout that maps well to this more regular notation. In practice, attempts to do that have generally failed and it's hard to see how to make it work.
The irregular spacing of the current piano layout can be frustrating, but it fits under the fingers pretty well, and it's very useful to be able to identify notes at a glance.
If it's free, though, who pays for your hosting?