Our goal isn't to replace production ETL pipelines etc. We are building a place where you can quickly do an ad hoc analysis, share it with your whole team, and iterate on it.
If it's small and works great you're all set. If your work out grows Quadratic just take the Python and SQL code from Quadratic, modify it slightly, and deploy it on more robust infra.
> Our goal isn't to replace production ETL pipelines etc.
Why not? The OP is conflating accidental complexity in current spreadsheet design, there is no reason that you couldn't get a graph of code. Everything becomes production, or mission critical at some point. There is no difference. Production ETL pipelines exist because spreadsheets have historically only run a single machine, hence the whole "big data" definition.
I am absolutely sure you are familiar with https://en.wikipedia.org/wiki/Felienne_Hermans and ZUIs, your work is the intersection of both.
I kinda hope you are pandering to the HN gestalt against spreadsheets. But yes, please do introduce fork/merge/diff (you already have-to to support multiple simultaneous users). As well as property testing.
Aside, I am kinda losing my _, that you pulled all of this off. I absolutely love it. Amazing, hopefully we have a future to thank you.
And it was all done in a Excel spreadsheet.
Each night a bunch of traders would each kick off scripts in Excel. The script would download the new ratings (S&P, Fitch, and Moodys) for each bond, download the new LIBOR curves, update the spreadsheet, save a copy (y'know, for backup purposes and history), then generate an XML file, shell out to the risk tool provided by the quants, then parse the XML result, load it back into the spreadsheet, let it crunch and then FTP it to the central risk server.
Each deal was a separate spreadsheet, and there were about 30 of these deals. Some of the runs would take ~20 hours, so they were basically always running, but most of them took about an hour. The sheets were a spaghetti mess of formulas, often with errors or inexplicably different formulas.
I also am cynical, and I can't imaging supporting something with even more programming ability.
I'll buy into this in a second, however, if you find a way to defragment the logical mess of a spreadsheet and turn it back into functional transformations of tabular data, such that we can implement it into stream processes or ETL pipelines. Otherwise you're just letting the next generation of corporate workers fall into the same trap of embedding their business logic lazily into a digital grid cemetery that'll end up wedged into the onedrive file pile.
(Apologise if this comes across as cynical, from an implementation perspective you've done an amazing job, I just hate spreadsheets)