mito

table formulas by about 5x. 4. We generate test cases for our translations as well, to make sure the Python process matches your Excel process. 5. We give you back a Jupyter notebook that contains the code we generated. If there are pieces of the Excel we can’t translate successfully (complex formulas, or pivot tables currently), then we leave them as a TODO in the code. This makes it easy for you to hop in and continue finishing the script. Who is this for: Developers who know Python, primarily! Pyoneer might be useful if: 1. You’ve got an Excel file you’re looking to move to Python (usually for speed, size, or maintenance reasons). 2. There’s enough logic contained in the notebook that it’s going to be a hassle for you to just rewrite it from scratch. 3. Or you don’t know the logic that is in the Excel workbook well since you didn’t write it in the first place :) Post translation, even if Pyoneer doesn't nail it perfectly or translate all the formulas, you'll be able to pop into the notebook and continue cleaning up the TODOs / finish writing the formulas. What the Alpha launch supports: Launched early! Currently we’re focused on supporting: 1. Any number of sheets, with any reference structure between them. 2. Cells that translate as variables directly. We’ll translate the formulas to Python code that has the same result, or else we’ll generate a TODO letting you know we failed translating this cell. 3. Tables that translate as Pandas dataframes. We support at most one table per sheet, at the tables must be contigious. If the formulas in a column are consistent, then we will try and translate this as a single pandas statement. We do not support: pivot tables or complex formulas. When we fail to translate these, we generate TODO statements. We also don’t support graphs or macros - and you won’t see these reflected in the output at all currently. Why we built this: We did YCS20 and built an open source tool called Mito(https://trymito.io). It’s been a good journey since then - we’ve scaled revenue and to over 2k Github stars (https://github.com/mito-ds/mito). But fundamentally, Mito is a tool that’s useful for Excel users who wanted to start writing Python code more effectively. We wanted to take another stab at the Excel -> Python pain point that was more developer focused - that helped developers that have to translate Excel files into Python do this much more quickly. Hence, Pyoneer! I’ll be in the comments today if you’ve got feedback, criticism, questions, or comments.

for display is _expected_ in an Excel format. The two main reasons for this are just organizational momentum, or that you want to let the receiver conduct additional ad-hoc analysis (Excel is best for this in almost every org). The way we've sliced this problem space is by improving the interfaces that users can use to export formatting to Excel. You can see some of our (open-core) code here [2]. TL;DR: Mito gives you an interface in Jupyter that looks like a spreadsheet, where you can apply formatting like Excel (number formatting, conditional formatting, color formatting) - and then Mito automatically generates code that exports this formatting to an Excel. This is one of our more compelling enterprise features, for decision makers that work with non-expert Python programmers - getting formatting into Excel is a big hassle. Of course, for folks who can ditch Excel entirely, this is entirely unnecessary. Great Tables seems excellent in this case (and anyone writing blog posts this good is probably writing good code too... :) ) [1] https://trymito.io [2] https://github.com/mito-ds/mito/blob/dev/mitosheet/mitosheet...

igma has this as their goal - mockup the website in Figma, it generates the code for a website (you don't see this code!), and then you can click deploy _so easily_. Who wants to bet that hosting services like Vercel etc reach out to Figma once a week to try and pitch them... In the meantime, while we have websites that don't fit neatly inside Figma constraints, while developers are easier to hire than good designers (in my experience), while no-code tools are continually thought of as limiting and a bad long-term solution -- Figma code export is good. > Why is just writing the code by the hand not the best solution? For the majority of us full-stack devs who have written >0 CSS but are less than masters, I'll leave this as self-evident. > So you do want to do code-gen, does it make sense to do it in a chat interface, or can we do better? In the case of Figma, if they were a new startup with no existing product and they were trying to "automation UI creation" -- v1 of their interface probably would be a "describe your website" and then we'll generate the code for it. This would probably suck. What if you wanted to easily tweak the output? What if you had trouble describing what you wanted, but you could draw it (ok, OpenAI vision might help on this one)? What if you had experience with existing design tools you could use to augment the AI. A chat interface is not the best interface for design work. ChatGPT-style code-generation is like v0.1. Github Copilot is an example of next step - it's not just a chat interface, it's something a bit more integrated into an environment that make sense in the context of the work you're doing. For design work, a canvas (literally! [2]) like Figma is well-suited as an environment for code-gen that can augment (and maybe one day replace) the programmers working on frontend. For tabular data work, we think a spreadsheet is the interface where users want to be, and the interface it makes sense to bring code-gen to. Any thoughts appreciated! [1] https://trymito.io, https://github.com/mito-ds/mito [2] https://www.figma.com/blog/building-a-professional-design-to...

can see the final PR here: https://github.com/mito-ds/monorepo/pull/751). It takes a similar approach to the top comment (passing a subset of the data to the LLM), and then really focuses in the UI around "what changes were made." There's a lot of opportunity for growth here, I think! Any/all feedback appreciated :) EDIT: Also, shout out to JupyterAI (https://github.com/jupyterlab/jupyter-ai) -- it's an official Jupyter project with some really awesome LLM support directly in JupyterLab. I saw it debuted at JupyterCon last week :)

le. Check it out if that’s your thing [2] [1] https://trymito.io [2] https://GitHub.com/mito-ds/monorepo

of those parameters, and then write most of the 4-6 boilerplate Python and Typescript files I need automatically! You can see it here [2]. This is still metaprogramming (it’s certainly code that writes code). But the code you end up with at the end of the day is very simple Python code that is extremely easy to understand / maintain long-term. I’ll pass on the fancy stuff for now. Thanks though! [1] https://trymito.io [2] https://github.com/mito-ds/monorepo/blob/dev/mitosheet/dev/c...

ey just aren’t experts in Python. Tasks that take them seconds in spreadsheets can end up taking them days. (Here’s how we put it to investors: the next 10 million Python programmers are transitioning from Excel and have one real problem: writing the damn code.) A lot of organizations are stuck on this dilemma: they want to move from spreadsheets to Python, but getting started with programming—even with a highly usable language like Python—is hard. We’ve spent years with users trying to adapt their spreadsheet skills to Python. It takes weeks to learn the basics. Their existing skills don't transfer. Many of their needs are simple to do in a spreadsheet—writing a formula, aggregating data, graphing—but adapting them to Python requires long courses, emails to internal support (if any exists) waiting days for a reply, and countless trips to Stack Overflow. Often they just give up and return to Excel, but that makes them dependent on IT to write code for them. One of our users was quoted a full year for IT to implement a simple report! (Fast-forward: he ended up using Mito to automate it himself in less than a week.) We went through this ourselves when we went to college together, studying engineering and business. We first learned data science with spreadsheets, then had to relearn it in Python. The transition was painful—basic Excel was much easier! Of course, not-so-basic Excel soon becomes not-so-easy, which is what drives the move to Python in the first place. With our interest in spreadsheets, we started a spreadsheet-version-control company at the end of college, and spent a year working with Excel power users. Eventually, we realized that version control was secondary to the real problems users faced with spreadsheets: limited data size, speed limits, lack of advanced functionality, and a horrible replayability story. Essentially, enterprises are caught between a rock (their spreadsheet woes) and a hard place (the pain of moving analysts to Python). We decided to work on this instead, and started Mito. Mito is a spreadsheet UI built as an extension to Jupyter Notebooks / JupyterLab. Using a Mito spreadsheet, users can import data, add and delete columns, write formulas like Excel, make pivot tables, generate graphs, and more. See our docs (http://docs.trymito.io) for all our functionality. Every tab in a Mito spreadsheet is a different pandas DataFrame. For each edit made, a line of pandas code is generated in a code cell directly below the spreadsheet that corresponds to this edit. For example, if I use Mito to import a CSV, add a column named Day of Week, and use the WEEKDAY formula from Excel to pull out the weekday from another column, Mito generates the following code: # Imported tesla stock.csv import pandas as pd tesla_stock = pd.read_csv(r'tesla stock.csv') # Added column Day of week tesla_stock.insert(1, 'Day of week', WEEKDAY(tesla_stock['Date'])) In practice, the typical user bounces back and forth between writing Python and using the Mito spreadsheet, depending on the task at hand. We think this fluid movement between a spreadsheet and Python is really cool. The spreadsheet backend is just a Python extension to the IPython kernel you’re already running for your Jupyter Notebook. Because Mito is just a Python package, all data processing happens locally. As mentioned, Mito is an open core product. 90% of the code is AGPL licensed. The rest is under a separate enterprise license. These modules are still source-visible, but require users to pay for a pro or enterprise offering before using them. That’s basically our business model. We have 3 versions (https://trymito.io/plans): (1) Free: basic analysis tools, as well as some basic telemetry that you can opt out of; (2). Pro: all of (1), with advanced functionality; (3) Enterprise: all of (2), with more advanced features, optimizations, and support. Because spreadsheets are sprawling pieces of software, we’re pretty obsessed with optimizing for long-term development. We use strong types where we can (TypeScript on the frontend, fairly comprehensive MyPy in Python). We’ve implemented our own component libraries for common components from scratch, which lets us be flexible during large refactorings. We implemented our own custom JavaScript grid—hyper-optimized for our use case, and as a result is the fastest JS grid we tested in our context. We're also big fans of metaprogramming—we write an increasing amount of code that writes code for us—which in turn makes it easy to add more functionality to our spreadsheet. We posted about Mito a long time ago: https://news.ycombinator.com/item?id=24305615. No one really liked it (we learned our lesson!), and it didn't do much at the time — I think the app had a single button that added a column. Three months ago, someone (not sure who — thank you, alefnula!) posted it again: https://news.ycombinator.com/item?id=31446236. It reached the top 3 and we got lots of comments—yay! Since then, we’ve doubled the number of features (mostly data processing), done a UI overhaul, dramatically expanded the Pro + Enterprise offering, made telemetry optional in the free version, and more. We’d love to hear all about your experiences with spreadsheet analysis, the uncanny valley between spreadsheets and code, the travails of moving enterprise analytics off of spreadsheets, and whatever else you’d like to ask or mention. Any and all feedback is greatly appreciated!

re not one of those users and using the open source version, then you will always have access to Mito (and can even help improve it!). Of course the line between what features are specifically helpful in an organization and what feature are needed for an average analysis is a bit blurry, and is a moving target as we continue to expand Mito's offering. 2. Mito is designed specifically to not force users to make a big 'switch'. I've commented this elsewhere in this thread, but just to recap: Because Mito is an extension to Juptyer and because we generate python code for every edit you make, Mito is designed to improve your existing workflow instead of lock you into a new system. Many Mito users use Mito as a starting point! They do as much of their analysis as they can in the Mito spreadsheet and then continue writing more customized Python code to finish up their work. Not requiring a big switch is nice for the user and its nice for Mito too! Lots of large companies have been able to get up and running with Mito in 30 minutes because it fits into their data stack. Anyways, not that these are the only two reasons you might feel uneasy about adopting Mito, but at least wanted to share why the switch to Mito might be less scary than switching to other tools. [1] https://github.com/mito-ds/monorepo