4 ms·

I've been thinking about a terminal spreadsheet editor for about a year now. I haven't deeply investigated this tool while I write this comment but I'd love for

I've been thinking about a terminal spreadsheet editor for about a year now. I haven't deeply investigated this tool while I write this comment but I'd love for something like this for Terminal that supported `=A1+B2` kind of formulas.

runjake 3y ago
Back in the day, we called this Lotus 123 and VisiCalc. https://en.m.wikipedia.org/wiki/Lotus_1-2-3 https://en.m.wikipedia.org/wiki/Lotus_1-2-3
- zoogeny 3y ago
  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.
- PaulHoule 3y ago
  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 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.
  - wlindley 3y ago
    We had that once, in an MSDOS-era program called Javelin ( https://en.wikipedia.org/wiki/Javelin_Software 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!)
  - bee_rider 3y ago
    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.
franek 3y ago
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/andmarti1424/sc-im/ https://github.com/dhruvasagar/vim-table-mode 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.
genericacct 3y ago
I wrote an SC fork that does this ,will send a link when im home

runjake 3y ago

Back in the day, we called this Lotus 123 and VisiCalc. https://en.m.wikipedia.org/wiki/Lotus_1-2-3 https://en.m.wikipedia.org/wiki/Lotus_1-2-3

zoogeny 3y ago
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.
PaulHoule 3y ago
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 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.
- wlindley 3y ago
  We had that once, in an MSDOS-era program called Javelin ( https://en.wikipedia.org/wiki/Javelin_Software 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!)
- bee_rider 3y ago
  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.

franek 3y ago

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/andmarti1424/sc-im/ https://github.com/dhruvasagar/vim-table-mode 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.

genericacct 3y ago

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