The world runs on spreadsheets, and for good reason: they are a universal data canvas. But building on top of and around the spreadsheet is clumsy: limiting scripting environments, APIs and file formats get in the way of making the spreadsheet a part of a broader application. Excel workbooks become monolithic and unmaintainable. Google Sheets data become static and stale.
Both Excel and Google Sheets offer some level of programmability but we have yet to find any user who liked the experience. It’s harder than it should be, using programming languages that are more limited than you expect. With Excel you've either got VBA or an extension like pyxll to deal with. With Google Sheets, your options are AppsScript or the REST API. These tools are mediocre but the need for programmable spreadsheets is such that people use them anyway.
With Neptyne, the spreadsheet itself runs in the Python runtime, so you can write to it or read from it like an in-memory data structure, because that's exactly what it is.
Neptyne primarily solves problems that exist at the boundaries of what other spreadsheet tools can do. We make Python a first-class citizen of spreadsheet-land, meaning you don't need a clumsy integration or extension to make your code work with spreadsheets. You can use standard off-the-shelf Python libraries to build on top of an Excel-like spreadsheet environment to build collaborative applications. You mix Excel style cell addresses (A1, C3) and ranges (B2:B20) with Python code (e.g. `A1 = "foo" if B2 > 0 else "bar"`, or `for num in B2:B20:`).
Before starting Neptyne we worked at Sidewalk Labs, where we built models in Python that would typically be shared or used via spreadsheets on an interdisciplinary team. The final step of many pipelines was "write a .csv with the results", which was a great way to share data but only in one direction. What we really needed was a way for users to interact with our Python models through a spreadsheet: tune inputs, see results, make quick aggregations. After making some version of this work with the Google Sheets API, we knew this could be better. What we wanted was basically a Jupyter notebook embedded in our spreadsheet, that could give us the full power of Python while keeping the accessibility of a spreadsheet. We built a proof of concept, found some interest in it, and formed Neptyne.
Neptyne differs from lots of modern takes on the spreadsheet tool in that we really wanted to preserve the "data canvas" nature of a true spreadsheet. While there is value in making spreadsheets more like SQL databases with column-based types and formulas, Neptyne gives you the freedom to structure your spreadsheet as you would with Sheets or Excel. Mix and match data types, table dimensions, graphs, charts, and buttons as freely as you might with those tools.
Neptyne behaves exactly like a spreadsheet but is secretly an alternative frontend to a Jupyter Notebook that has an embedded spreadsheet engine. Because it runs a Jupyter kernel, we support anything you can run in a Jupyter notebook, including all the expected visualization packages (matplotlib, plotly, etc.). This is not merely scripting using Python—you can use any (stateful) Python framework to get serious work done.
Things users have built with Neptyne so far include a Twitter bot, a private spaceflight schedule optimizer, and a CRM that pulls from several different data sources.
Neptyne's basic tier is free to use. As we add more capabilities to the product, certain features will be introduced at paid tiers. For individuals building interesting stuff to be shared with the community it will always be free. For teams that need private documents, sharing and custom images, we will charge a team fee.
Here’s a link to some videos: https://www.youtube.com/@neptynehq that show how Neptyne works. If you really want to get a sense of the product, the best way is try out our three minute tutorial: https://neptyne.com/neptyne/tutorial.
We’d love to hear about things you’ve built in spreadsheets and what new things might be possible with a native Python integration! Fire away!
I ran through your demo and I have some feedback:
- Tab completion in the REPL would be great.
- When I change code in the editor, it doesn't update the cell where that code is used until I click on the cell, click away, and click back.
- When I ran the append function, it worked, but if I look at the array in the cell, it's unchanged. If I click on the cell and hit enter, it wipes out the append. I'm honestly not sure what the right behavior here is, I can see use cases on both sides. But initially I did expect the cell with the array to update with the new array.
- When I tried to do autocomplete on the capitals, it failed silently. I assume the API failed to fetch the capitals? It worked on the second try (but took a while).
- When I add a column into the sheet, it breaks all the code that has cell references. I'd expect the code with cell references to get updated unless my references are $F$4 for example, just like in the sheet itself.
Overall though this is a great start!
* The REPL is supposed to do autocomplete where it makes sense. If you enter A1. it should show you a list of things you can do there. That always feels better than asking for it explicitly. Let me know if that doesn't work.
* Yeah, code changes don't rerun the affected cells. It is something we've debated, and maybe we should? It feels like it could also cause unexpected things to happen. Hmm. Maybe we should though.
* This is tricky. Spilling from a function, doesn't fill the cells and then append does. Open for suggestions on how to make this better.
* We call the OpenAI API - they don't always answer these days :-(
* That's a good point. We should fix that!
> Yeah, code changes don't rerun the affected cells. It is something we've debated, and maybe we should? It feels like it could also cause unexpected things to happen. Hmm. Maybe we should though.
You know your customers better than I do. :). But generally when I use spreadsheets I expect bidirectional connections and updates.
> This is tricky. Spilling from a function, doesn't fill the cells and then append does. Open for suggestions on how to make this better.
I honestly don't know. Depends on your user's use cases. Even just for me I can see cases where I would want the cell updated and others where I wouldn't. Heck maybe even just ask the user "Do you want to update the cell?"
> We call the OpenAI API - they don't always answer these days :-(
That's fine, just tell the user it failed. :)
Yikes. That's worrying. Is this rate limiting or API timeouts that need some retry logic wrapped around?
I was complaining just today because I pasted some records into Excel and it decided to treat 933349234275230104 as a number (it's a hash), convert it to scientific notation (which I NEVER want), and lose precision. Yet there is no way to globally disable scientific notation. Plus it's kind of insane that "formatting" changes data in the first place.
I frequently paste timestamps into Sheets or Excel and it just ruins everything. If split-to-text puts the date part in one column and the time part in another, I can't put them back together with a simple string concatenation, because again "formatting" turned my date text into Excel's weird internal number. This is legacy behavior that Excel has to keep for backward compatibility, but I don't want it, and I wish I could turn it off.
Sometimes I'll try to scatter-plot 5 series against a timestamp, and Excel will decide all 6 columns are series, even though a scatter plot with no X-axis makes zero sense. Even when it does work, Excel seems stubbornly uninterested in understanding how dates/times work, and I can't do simple things like tell it to have an X-axis tick every day/week/month.
If you are building a spreadsheet in 2023, the #1 goal should be leaving behind all the baggage, even if it has to be behind a toggle. Listen to what people find frustrating about Excel (tip: it's gonna be dates) and fix that.
If you can do that, then yeah, Python! Woo! Neat! But that's not going to be the main draw, because it's not a solution to the main problems that spreadsheets have.
I wish you good luck and all the best. It's a tough field but a big market. And I still think the potential is there.
Well, that's unfortunate for "power" users - I'd imagine they'd want what excel calls r1c1 mode:
https://learn.microsoft.com/en-us/office/troubleshoot/excel/...
One of the many valuable lessons from Joel Spolsky "You suck at Excel" (around 8:30 mark): https://youtu.be/0nbkaYsR94c
For what I mean see: https://excelchamps.com/formulas/r1c1/
It seems a web version of the app has been published in open-source[3] but that too has been EOL.
[1] https://web.archive.org/web/20120211201410/http://www.resolv... [2] https://www.resolversystems.com [3] https://github.com/pythonanywhere/dirigible-spreadsheet
Thanks for mentioning this! I came across Resolve One recently in another HN thread. Were you a user yourself? What did you think of it?
All our clients had stacks of sedimented business rules and know-how, lying around in a mess of unreliable, unmaintained and un-versioned Excel files.
I was thinking of using Resolve One as a conduit that might be helpful to absorb all of that. A UI similar to a spreadsheet would be a clever trojan for adoption, as I could win the hearts and minds of the users that were not seeing themselves as developers. While bringing better software engineering and QA in the enterprisey world of organically grown, ad-hoc solutions.
Neptyne seems to revive that grand vision, so it would be interesting to study how and why Resolve One failed. Too soon perhaps, as the market wasn’t as big as it is today? Or maybe by the time you reach the critical point of the messy pile of Excel docs, you consent to invest into your core business and hire internal developers. I’d love to read a post-mortem of Resolve One.
I was very sorry to see the project go insolvent. I didn't become an active user due to accident of time not discovering it until the final months.
Deleted Comment
Dead Comment
https://help.gnome.org/users/gnumeric/stable/sect-extending-...
I recall doing a noise model of a transimpedance amp in Gnumeric where I called out to Python/Numpy to do integration of 1/f noise based on parameters from a datasheet. That was at least 10 years ago. What's the difference between this Gnumeric feature and Neptyne?
My unsolicited advice (that's probably on your radar anyway) would be to try and get a management consulting firm on board with this. The flexibility this has would be well used there, and you've got lots of people who are engineers stuck using spreadsheets that would be on board with trying something like this.
Our biggest challenge as you say is definitely the fact that lots of users will be entrenched in Excel. Our goal right now is to appeal not to those who are happy in Excel today, but to those who have grown disillusioned: lots of users today build up amazingly complicated things in Excel and grow frustrated by the difficulty of maintaining that complexity. Python can be a much better fit in many cases for a lot of that complexity.
And as a platform for data science, we've found Neptyne really nice for sharing results. I was surprised at how often I heard from users: "well, we usually do everything in Jupyter, but then whenever management wants to see the output, they ask for it in a spreadsheet".