While not built around CSV, two terminal spreadsheet tools I have successfully used in the past are sc-im and the (neo)vim plugin vim-table-mode:

https://github.com/andmarti1424/sc-im/

https://github.com/dhruvasagar/vim-table-mode

Back then I stopped using sc-im because it could not import/export XLSX, if I remember correctly. Apparently it can today!

vim-table-mode always felt a little fragile and I don't want to be bound to vim anymore. That said, it still feels like a small miracle to me to have functional spreadsheet formulas inside markdown documents – calculation and typesetting all in one place.

Back in the day, we called this Lotus 123 and VisiCalc.

https://en.m.wikipedia.org/wiki/Lotus_1-2-3

The spreadsheet data model lives a double life.

(1) On one hand you can use it for data that is really tabular,

(2) But it also has an engine that can compute the dependency relationships between cells and recalculate the cells affected by a change. This is quite different from conventional programming languages where you are required to specify an order to put operations in. Of course this a problem for exploiting parallelism but I'd charge it is one more bit of cognitive load that makes it harder for beginners and non-professional programmers. (Professional programmers are just used to it and only run into problems in unusual cases where circularity is involved, but I think it's one more thing that beginners struggle with.)

The worst problem is a lack of separation between code and data. If you are doing an analysis you might put something like

  =SUM(A1:A28)

in A30. Excel will change that to

  =SUM(A1:A29)

if you insert a row in there, which helps, but they lock you into the mindset of "I'm making the December sales report" as opposed to "I'm making the monthly sales report". That is, the data and the analysis should be two separate things: just as you can put the December data or the January data into a Python script.

(Note some of the same problems still exist with "notebooks" and "workspaces" where you wind up with a file that has both code and data in it which can be problematic to check into git, particularly when your are working for people who would like to have a beautiful notebook with an analysis in it to view in GitHub but will then struggle to version control it. Many "data scientists" fail to rise above the December sales report even though there's a clear path to turn a Jupyter notebook into a Python script.)

---

As much as that is a rant I think there's a huge untapped market for things that are like spreadsheets but different. That is, something that looks like Excel but is specialized for editing tabular data (no formulas, CSV import 'just works' all the time, ...) or something that has formulas like Excel but not on a grid or not just on a grid. For the latter there was this product

https://en.wikipedia.org/wiki/TK_Solver

which is still around. People were amazed with TK Solver when it came out and I'm surprised to this day that it hasn't had a lot of competition.

We had that once, in an MSDOS-era program called Javelin ( https://en.wikipedia.org/wiki/Javelin_Software ):

"Unlike models in a spreadsheet, Javelin models are built on objects called variables, not on data in cells of a report. For example, a time series, or any variable, is an object in itself, not a collection of cells which happen to appear in a row or column... Calculations are performed on these objects, as opposed to a range of cells, so adding two time series automatically aligns them in calendar time, or in a user-defined time frame. Data are independent of worksheets..."

That was forty years ago and as far as I know there hasn't been a program that works the same way since. Perhaps someone could reverse-engineer it (the jav.exe file is only 56,448 bytes!)

Spreadsheets are kind of interesting tech. Because the user is more-or-less directly building the data dependency graph, I’d expect them to map better to actual hardware (massively parallel in so many dimensions) better than a sequential procedural language like C.

But, they are not very fashionable.

It would be fun to have a pipeline to compile a spreadsheet, that produces an executable. Potential outputs: cpu, gpu, fpga. Haha.

Yes, exactly - imagine a modern version written in Rust, with vi key-bindings, etc. Please someone be inspired by this idea and build this. TUIs are making a comeback and the spreadsheet is still one of the most useful and effective tools in all information science.

I wrote an SC fork that does this ,will send a link when im home