Comment by narush | Hacker News Reader

Comment by narush | Hacker News Reader

Warning: I'm a founder working in the spreadsheet space, so take the rest of my this comment with a (large) grain of salt. I've written before [1] (HN and elsewhere) about how I think spreadsheets are the most popular programming paradigm ever, we just don't talk about it much. As this article mentions, there are many ways we can push this forward.

I personally think the most powerful low-code spreadsheet tools we can build are those that allow spreadsheet users to easily transition to full programming languages, if they want to. So rather than locking users into limited and proprietary product number #115 (some of them are mentioned in this article), IMO it's better if users can transition to a full programming language (like Python) very naturally. Som I've spent the past 2 years building Mito [2].

Mito is a spreadsheet extension to your JupyterLab environment. You can display any Pandas dataframe as a spreadsheet, and edit it in a very similar way to Excel. For each edit you make, it generates the corresponding Python code below for those edits. Practically, you can think about Mito as recording a macro, but instead of generating scummy-crummy VBA code, it generates Python.

We're open core [3]. Feedback greatly appreciated!

[1] https://naterush.io/blog/Spreadsheets-are-the-Ultimate-Progr... [2] https://trymito.io [3] https://github.com/mito-ds/monorepo

Shouldn't your product be independent of Jupyter? Jupyter is amazing but still seems to have a beta feel to me as often old Jupyter notebooks will not work at all (for lots of reasons).

I love python, hate the limits on google sheets apis, and don't really honestly think VBA is "scummy-crummy" it is just unsupported. Microsoft made a huge mistake discontinuing real Visual Basic, as it honestly could have been where Python is now, instead VB.net is basically dead, and the momentum Microsoft had with wysiwyg code editing is way behind where it was.

Very cool that you are generating code for the Jupyter notebook. What are the practical row limits as I see that as one reason someone might use Pandas instead of Excel?

The main benefit (to our users) of being in Jupyter is that we don’t have to force them to switch up their whole workflow. If they want to layer on a spreadsheet, bring an extension mak it easy to do this. We don’t want to lock people into our platform vs just provide the best spreadsheet experience we can!

For us, it’s nice because we don’t have to reinvent the wheel(s) that Jupyter comes with :-)

You need the commercial license to disable telemetry? That's... new.

Yeah that’s fair feedback. Our Pro features are a WIP currently, so this might evolve in the future. It was important to us that there is a way to be totally telemetry-less if users prioritize that - vs most other cloud based sass data science tools where you pretty much have no hope of total privacy.

> That's... new.

Sadly, it isn't. Microsoft set the precedent with Windows 10's telemetry, which they only give you a setting to turn off if you bought Enterprise Edition.

This sounds reasonable to me? In exchange for telemetry data, you get to use this product without paying a single cent.

Wait, so, you're trying to make programming languages accessible to spreadsheet users, by giving a new spreadsheet to programmers?

Mito looks very cool! Looking forward to trying it.

The blending of spreadsheets and notebooks seems inevitable. One trend notebook-as-program. I've heard several variations of this: "The data scientists give us a notebook, and our automation runs the notebook to do <ML thing> on <our internal data sets>". It's clunky to use a format initially intended for interactive visual use for headless automation, but there's a practical wisdom to sticking with whatever format the data scientists prefer. Twenty years ago, I saw the same sort of thing with engineers and spreadsheets.

The one thing notebooks lose, though, is data flow computing. That's a major strength of spreadsheets, and the imperative execution of notebook cells seems like a step backwards. Although I'm sure somebody has bolted some kind of inter-cell dependency execution onto Jupyter by this point.

Just curious, why as a Linux user shouldn't I use Libreoffice calc with python? Why bring in something so proprietary?

Mito isn’t just a spreadsheet that works with Python, but a spreadsheet that allows you to generate Python code when you edit!

If your just looking to work with spreadsheets with Python, I’d also reccomend checking out XLWings - I haven’t used it myself but some of our users do and love it!

Seemlessly integrating spreadsheets into jupyter sounds like the holy grail to me. I haven't tried it yet, though.

I think their users are people like me - who work a lot in Jupyter and swear by it - in a Python data analysis/visualisation environment. To bring in the best of spreadsheets into that could be magical. To just work in libreoffice calc or Excel would be a nonstarter, it just doesn't match all the other python tools in the workflow.

Another direction here is reactive notebooks where when you change one field in the notebook all of the dependent fields are automatically updated. Pluto.jl for example [1]. It has the feeling of a cross between a Jupyter notebook and a spreadsheet without looking like a spreadsheet.

[1] https://github.com/fonsp/Pluto.jl

> We're open core [3]

What does that mean? The citation doesn't mention "open core", but does say Mito is open source.

"Open core" means that most of the software is open source, but that some pieces of it are proprietary. See here: https://github.com/mito-ds/monorepo/blob/c4e225e7fcb1caea930...

Thanks. I'm a bit dubious about using the jargon - which people can easily misunderstand - isntead of saying, "mostly open source components, some priopriatary ones".

Reply on news.ycombinator.com