This looks cool and is well made, but god do I hope my company does not let this become common place. We already struggle with company logic being buried in spreadsheets, brains and walled garden software. The last thing we need is to encourage this modern business anti-pattern of experts implementing their work in byzantine, opaque, impenetrable gardens of logic-data spaghetti bowls.
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)
Back in the mid aughties (circa 2006) I was doing risk analysis at a big bank. The kind of international bank that you read about on a regular basis in the news. Our team supported synthetic bond-backed collateral debt obligations, and this was all principal finance, so the bank investing its own money. We didn't have clients that we had to support. But we did have to generate our risk profile each night and FTP it to the central server.
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.
Back in 2014 I was contracted to do spreadsheet devops when a similar spreadsheet went rogue and cost the company some 10m dollars: It stopped updating exchange rates because yahoo finance did something with their API.
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.
This is for the room. You understand all of this stuff.
> 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 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.
Is there a way to view the formula / python code alongside the cells? As in have it permanently visible? So many spreadsheet operations could, maybe should, be tabular operations.
i hear you but also it wouldnt be too too hard to consume data from your source of choice and to expose data for consumption elsewhere. a fully reactive spreadsheet is in some ways a lot better for a smooth upgrade path from “just trying things out” to “ok it’s in production now” - the holy grail.
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)