>When Visicalc was released, Perez became convinced that it was the ideal user interface for his visionary product: the Functional Database. With his friend Jose Sinai formed the Sinper Corporation in early 1983 and released his initial product, TM/1 (the "TM" in TM1 stands for "Table Manager"). Sinper was purchased by Applix in 1996, which was purchased by Cognos in late 2007, which was in itself acquired mere months later by IBM.[3][2]
TM1 is widely used as a way to interface with official ledgers.
Yup, I have. And had to deal with converting "this awesome tool that does X, Y and Z" to an actual multi-user app because it was just so great. You end up discovering that there are tons of miscalculations in these formulas that only surface when you start writing tests for them, and that a lot of the business decisions based on these tools had flawed assumptions.
Having said that, I love that Excel has democratized app-building and made it easier for people to solve their own problems. In terms of alternatives, I think it's more about the UI and mental model that people have when using Excel, not necessarily the functionality. There may be 1-to-1 competitors in terms of functionality, but in terms of UX, Excel is sort of king.
My first job out of uni was developing a devops pipeline for Excel spreadsheets after one went rogue and cost the broker trader I was hired by $10m in one fun afternoon.
An application I consulted on was a web interface that made heavy use of the Excel portions of Microsoft Graph so that the finance team could continue to send clients spreadsheets that they could adjust without also sending them the formulas to "steal" (and take other parts of their business elsewhere, to noticeable millions of dollars of project spending habit shifts). The finance team wasn't going to stop using Excel ("how dare you suggest it"), so it was wildly custom solution to figure out where formulas existed in any of the spreadsheets finance felt like giving to the app, build a custom UI for entering the inputs to those formulas, run those formulas most with Microsoft Graph cloud magic/some with other web libraries, and return the results.
If it were just about any other group than that company's "finance department" that so deeply wanted "just tightly wrap Excel in a web UI and leave the key computations as Excel formulas we can continue to edit in Excel because all we want to understand is Excel" project would probably have been rightfully laughed out of the room. Finance has the keys to a lot of companies and like keeping those keys for comfort in Excel.
I would like to see the finance team that codes all their own C code and is adamant it needs to be in Emacs, especially because if they are that deep in Emacs I'd be wondering why they are insisting on C rather than Emacslisp or something even more esoteric like GNU Guile or someone's custom Forth to Fortran compiler…
But to answer the question, that is where I finished. We weren't "okay with it" that the finance team insisted on a C# to Excel files in SharePoint/OneDrive via Microsoft Graph turducken. We lived with it because the finance team had enough of the metaphorical keys to the car to be deeply in the driver's seat of that project. Sometimes you just have to grit your teeth and deliver what the customer wants.
I know a few people who use Quantrix for financial modelling. It is an exceptionally nice piece of software, basically the successor of Lotus Improv, with Improv's more robust and auditable separation of data and formulas.
I used Apple Numbers for all my spreadsheeting so it depends what you mean by "serious financial work". The vast majority of folk could probably get by without using Excel I am guessing.
