Also I wish there was a spreadsheet software that was more closely connected with something modern like Python. I want to be able to lean on Python to perform calculation while I have a particular spreadsheet open. Maybe even insert Python code into cells. That's difficult to do with Excel. I have experimented with LibreOffice Calc, and it may be possible there.

VBA is okay for writing simple functions & macros. But I don't like using VBA for anything more complicated than that. Maybe I haven't taken enough time to learn it. But at the same time I feel like I'm creating hacks for a language which should already have the features I want. Somewhat related: you'll see people online recommending that you set your objects to Nothing in order for the garbage collection to work. I have no way of knowing if I actually have to do that and I don't like doing things for no reason.

Is a commercial product to use Python inside Excel.

See https://support.microsoft.com/en-us/office/data-model-specif... and https://support.microsoft.com/en-us/office/create-a-memory-e...

Excel is the standard for a "polished" spreadsheet. It has been in development for about 40 years (since it was released in 1985) and has had the resources the most valuable company in the world can put into a flagship cash cow application.

It's-not-Excel is the primary pain point for all spreadsheet applications.

Documentation, training, third-party how-to's, etc. are one of the important ways that It's-not-Excel spreadsheets cause pain.

OK, sure the price of Excel is also a pain point and proprietary licenses are also one. But there might be very reasonable reasons for not focusing on users who prioritize those. Or not.

And Google Sheets and the Apple office suite already cost zero dollars, so there's that too.

Good luck.

I feel it always lags. I also tried to use their API once to e.g. upload data to a sheet but it was really messy.

In google sheets all this worked just fine.

A quick note: your spreadsheet had better support arbitrary-precision currency math, if it doesn't already. That's table stakes for a spreadsheet.

To answer your real question, I'd suggest doubling down on the sqlite side and taking things in a relational direction. Spreadsheets are good at tracking 1:1 or 1:many relationships, but my spreadsheets inevitably grow in a many:many direction and I find myself wishing for queries and junction tables.

In fact they even typically truncate or round the last few bits.

Our pain-points are almost entierly mundane:

* Macro-enabled Excel files, that can only be run on or by Windows.

* A endless log of Excel files that have errors. Most of these are files that are not compliant to the spec, but have been supported by various software over the years.

* User creating formats and overly complicated/brittle spreadsheet.

[1]https://basta.substack.com/p/no-sacred-masterpieces

I built Excel for Uber and they ditched it - https://news.ycombinator.com/item?id=37527720 - Sept 2023 (535 comments)

It’s often difficult to understand the state of a cell (what is it’s formatting and other rules)

It’s difficult to reason about what the underlying value of a cell is and it’s representation (e.g, 12-nov-22 == 12/11/2022) and what will happen when you change the value type of a cell

At least for excel, scrolling doesn’t follow curser. Cells are deselected when focus leaves a window.

It’s not like any of these are going to revolutionize the spreadsheet.

I think old versions of access had a front-end builder. Now MS have power apps, but it’s not very nice and the backend data store is also not great.

A spreadsheet backed app builder would be nice.

I wish I could name cells, such that my

E.g. allowing the application to be more visually clear when describing states of cells and the relationships between them, while giving one more freedom in the way those cells are then displayed.

Another thing I wanted is to be able to write extensions in C, and to work with non-Unicode text.

W.r.t non-unicode text: what's your use case?

Non-Unicode text, I want to be able to deal with text regardless of the encoding and character sets (although appropriate fonts will be needed in order to display it), without needing to conversion, so that any byte sequences can be used even if it is not a subset of Unicode.

(It does not necessarily mean that WASM is not also possible. If it is, then some kinds of native extensions might be possible to convert to WASM if you want the portability and security that it involves.)

This has serious consequences if I continue to make changes in the new doc when I think I'm still in the native doc (xlsx).

I find myself exporting to CSV, and then closing this CSV file, and finally reopening the original Excel doc.