Hacker News new | past | comments | ask | show | jobs | submit login

Thanks for posting! I love the topic - I've written before [1] about how I think spreadsheets are the most popular programming paradigm ever, we just don't talk about it much.

I personally think that the evolution of spreadsheets is less about changing the UI, and instead making it possible for spreadsheet users to easily transition to more powerful programming tools in a natural and easy way. So 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 currently have two types of users. 1) Excel users from a huge variety of industries who are somewhere in their journey to learning Python - and Mito helps them write Python scripts quickly and make that transition easier. 2) Python users who prefer using Mito because of it's visual interface. I pretty much only use Mito when I'm trying to pivot or graph data - some things really just are better visually, especially when you get code out that you can edit if you want!

We're open core [3], and also sell a Pro and Enterprise versions of the tool with advanced functionality. We've been steadily growing for the past year or so, as the product has improved (first time founder here!).

Feedback greatly appreciated!

[1] https://naterush.io/blog/Spreadsheets-are-the-Ultimate-Progr...

[2] https://trymito.io

[3] https://github.com/mito-ds/monorepo




I might have missed the point but the Mito demo just shows importing a CSV file into a common table/grid of cells? Seems like a semi-shamless plug that 100% avoids the topic of the post: is there a better visual data model than a grid of cells?


The question of "what is a better visual data model than VisiCalc" is just one of the questions we can ask ourselves about how to create Excel 2.0. In the authors original post, they point out that Notion and Coda answer this question not with an evaluation on "cells" and the data model, but rather by extending the model to include a word processor. This isn't a purely visual change, but a functionality/integration one.

There are a bunch of different angles to consider the evolution of a spreadsheet, and, as I say in my response above, I personally think focuses on changes to the UI/display of data miss the point: what's missing in Excel 1.0 isn't a better display of data - IMO, it's giving the modern, powerful analysis tools that us programmers have access to the beginner-end of the programmer spectrum!

Different spreadsheet startups certainly have different theses on this. Subset [1] (the OP) seems to focus on side-by-side grids on an infinite canvas. Monday [2] (also referenced by OP) seems to focus on different "views" for a spreadsheet for project tracking, etc. Mito focuses on allowing you to integrate Python and spreadsheets as easily as possible. Clay [3] seems to focus on spreadsheet integrations into APIs/other data.

(Disclaimer: all the above are just my understandings of these tools, but I haven't used most of them directly mostly am just going of marketing materials... I highly recommend you check them out, though - they all look quite cool!)

My post def was a plug for Mito - I'll try and make my response to the post/thesis more clearly delineated in the future. I think this post is an awesome chance to get feedback on our spreadsheet thesis (and potentially hear back from OP on this thoughts!).

Rock on, spreadsheets :-)

[1] https://subset.so

[2] https://monday.com

[3] https://www.clay.run


I don't feel that a grid of cells is the best visual representation for data. However, it is a natural representation for tabular data.

Tables are horrible for "visualizing". We didn't evolve looking at tables with hundreds of columns and millions of rows.

Once you learn some pivoting tools and charting, you can visualize things that you would never be able to find in a table of data. (Or if you did it would take a lot longer.)

(Sample size 1, but I teach Python, Pandas, and visualization (Jupyter w/ matplotlib/seaborn/bokeh). I've had clients tell me that one chart they came up with during a class on visualization more than paid for the training. They would have never seen that in the table of data. I've also found bugs in code by visualizing failure patterns.)


> I personally think that the evolution of spreadsheets is less about changing the UI, and instead making it possible for spreadsheet users to easily transition to more powerful programming tools in a natural and easy way. So I've spent the past 2 years building Mito [2].

Following the article idea of spreadsheet as the best paradigm, why you think users should abandon it in favor of other?


Spreadsheets are the best way to represent data, but there is a very long-tail of tasks one might to perform with their data. Requiring all of them to be built into a visual UI pretty much insists you end up with Excel - what feels like 1 billion features, where each user knows <1% of them (and costs millions of programmer-hours to build).

I don't think users can/should leave spreadsheets for the tasks spreadsheets make sense for (basic data munching, pivoting, many formulas, etc). But being able to easily transition your spreadsheet to other tools in a easy/native way is a huge win - and why at least half of our users are actually just Python programmers who use Mito because it makes that transition back and forth to spreadsheet/code so easy!

I don't think anyone should abandon tools if they are working for them :-)


I always encourage and applaud efforts to improve the stats quo, I suspect however that if there were a more efficient way for power users to quickly interact with data we would have found it by now.

In fact, to interact with large sets of data we have found it and it’s SQL. Again for power users. You data geeks are of course an exception and have a completely different set of tools.


From my experience, they are more likely to learn VB.NET, or eventually F#, seldom Python.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: