it's weird but Visidata is very nearly my idea of a perfect spreadsheet. "But!", you exclaim, "Visidata is not a spreadsheet", I know, I know, that is what makes it so weird. Let me explain.
I am not fond of the the usual spreadsheet data model. "It's a big bag of cell" does not fill me with joy. And upon a bit of reflection I think it is the rows, I really hate how easy it is for rows to get out of sync. All I really want is row security.* And this is what visidata brings to the table.
* Relational databases provide this in spades. and in truth most of my spreadsheets have been replaced by them(I maintain a local postgres server on my desktop for all the small random prototype junk you would usually do in a spreadsheet using visidata as a pager) And while the database is great for analysis, random data entry sort of sucks. There are some great tools out there for this. I don't tend to use them, mainly because psql is always there, so I just sort of grumble when I have to do random entry without trying to fix anything. Why postgres instead of sqlite? I like the types and functions better.
Another strong recommend for VisiData. I've been using it for a few years now, it's probably saved me months worth of cumulative effort in tasks I'd have otherwise used either spreadsheets or databases for. In fact, I almost never touch spreadsheets for ad-hoc data processing anymore.
This catches my eye every time, but for day-to-day work I always fall back to Google sheets. In light of that, this browser extension I found recently has been an absolute game changer: https://github.com/philc/sheetkeys
Because really, do you want all of vim in sheets, or just navigation (`i/h/j/k/gg/G/^u/^d`) and selection (`v/V`)? It has some other basic stuff, like `dd` and `o/O`, but otherwise conflicts with browser and Google functionality keep me away.
This is great and probably a nice complement if I can get it working with my Visidata[0] workflow for data files.
If you’re looking just for spreadsheets, Travis Ormandy somehow managed to get Lotus 1-2-3 to run on Linux a few years ago[1]. It’s a neat comparison point.
cursor-addressing uis likely have a higher barrier to entry (both for developers and users), so they are not suffering from the regression to the mean that has made modern guis absolutely unusable.
that, and there aren't any "ui/ux designers" specialising in cursor-addressing uis.
It reminded me of The Twin spreadsheet from the late 1980s. I worked at a plastics plant that used it in their color lab until at least 2013 when I left. There were thousands of color recipes and no one wanted to try and convert all of that to a newer spreadsheet.
The great drawback of TUI app is that are quite unusable from touch devices, or generally devices without a keyboard). If you find a way to make them usable on mobile I think they can get a great comeback
I gave sc-im a try years ago but quickly hit a showstopper for my needs. The built-in functions are very limited (for example no MEDIAN), but you can write your own external functions. However, external functions can only accept a single cell, and not a range of cells, as input. For me, operating on a range of cells is kind of the point of a spreadsheet. It seems that this hasn't been addressed yet.
This article made me recall a text based GUI? I used in commercial programming tool named "Vermont Views" previously named "Windows for Data" This was around about 1990 or earlier? . It was a tool that allowed relatively easy development of text based user interfaces Old Ad for it https://archive.org/details/byte-magazine-1992-01/page/n25/m... Google the words >> +"Windows for Data" Vermont Views << for lots other links ....
I really wanted to use this tool because I love Vim, but it just feels 'off' to me. I'm not sure why, though.
In a spreadsheet, I'm used to being able to move around with arrow keys and start typing immediately. Using SCIM, it feels like I'm constantly hitting a wall.
Despite that, I think the idea of a spreadsheet as a TUI is really great.
I think this is mostly dead for a reason. TUI nostalgia is an itch for software people, but software people already have more powerful things--like SQL, Pandas, APL, etc... while spreadsheets are for people who don't want to scale those learning curves, and those people already have Excel.
Back in the days before I found spreadsheets useful my boss was trying to get me excited about sc running on his HP workstation. That seems to be about the same time that one of the original authors was off working on something (Java) that would have more impact.
> sc-im is based on sc, whose original authors are James Gosling and Mark Weiser, and mods were later added by Chuck Martin.
This is really cool, but I don't think this is very useful.
In my opinion: if you can use vim, you can probably code, or at least figure it out without too much trouble. If you can code, then you don't need a spreadsheet. You can just write a program to crunch the numbers, or produce a report etc.
Excel is so popular, because it is a way for non-coders to crunch a bunch of numbers in a relatively easy way. And the best way to get the answers that they are getting out of the spreadsheet is to write code. But because they can't code, they have to use a spreadsheet.
If there is a use case for spreadsheets that is not better served by some real code, I'm interested to hear what it is.
You could also make the "speed" argument (just a quick calculation) for spreadsheets, but in that case, I find something like a python REPL just as quick, and still better anyway.
While vi might be a code editor first and foremost, not all vi users are coders. There are copy writers, academic and literature, having a need for fast and focussed touch typing (George R. R. Martin comes to mind as prominent WordStar user). The entire point of SGML/XML/HTML markup is to be able to create rich text documents without binary formats and special editors; this is also the case with Wiki syntaxes like markdown, which have been around since long before John Gruber's original Markdown.PL and are directly supported as a shortref customisation in SGML, from 1986, BTW.
Conversely, even if you are a coder, classic spreadsheets are extremely useful for any type of ad-hoc reproducible calculation (such as for taxes or other personal or business finance stuff). You really should check out spreadsheets if you haven't already; the point is that you can cross-reference cell values and copy/paste with relative cell positions to create large calculation tables/matrices, then update base values and perform "what-if" analyses, etc. etc. Using cell formulas is more like a logical programming language environment. I've used it for all kinds of reports apart from financials (benchmarks, construction/project planning, even a Tic Tac Toe game in school out of boredom).
I am a counter example to your assessment. I can definetly code, but I wip up spreadsheets often.
> If there is a use case for spreadsheets that is not better served by some real code, I'm interested to hear what it is.
Sharing information with non-coders could be an obvious one. I could have done a database with my wife's sewing patterns collection, of which she has ~300. Instead, I did a spreadsheet in google docs, which she's very familiar with. Told her how to enter data there (4 fields, name, file, tags and picture) and there's a couple tabs that allow her to filter things out, etc. Then she can do whatever she wants with it, like using conditional formatting to make dress patterns red. It was done in 2-3 hours, and she got exactly what she wanted.
I worked in a place where both the input and output was spreadsheets, and the users were spreadsheet users. We did implement a database for this particular one for the heavy algorithmic part, but a lot of the business logic (e.g. initial data validation, final presentation of the results) lived on the spreadsheets themselves.
Another interesting one is data-to-visual time. Unless you happen to be proficient in a particular area of programming (e.g. front programming with proficiency in something like D3, or R programmer) getting decent graphs out of data is a chore when going the programming route. With spreadsheets, you put the columns and get the graphs essentially for free.
To me spreadsheets are just another tool in the toolbox; they are appropriate for some tasks. They can definitely be misused and abused. Knowing which occasion is which is where experience comes in.
You forgot one thing: data entry. It is far more convenient to type tabular data in a spreadsheet app than in a REPL. I use it for simple SQL data, too. As Python coder I use visidata. Provides also fast and convenient aggregations etc.
And, btw, if you search for "distraction free writing",you will find that even some non-coders use vim.
> If there is a use case for spreadsheets that is not better served by some real code, I'm interested to hear what it is.
Think of spreadsheets as a convention-over-configuration low-code environment with a tightly coupled GUI for spinning up run-almost-anywhere apps that non-coders can modify. One of the few low-code environments that I actually like.
I'm a solopreneur whose SaaS product I coded from scratch. I love GPPLs, but I also create spreadsheets all the time.
Sometimes that's because of the stage of an idea: There's a new process you've discovered you need, but you don't have time to invest in building/buying/learning a tailor-made solution.
A case in point is a business overview dashboard I built to keep an eye on the metrics I care about. It pulls data from disparate sources using Power Query, which is built into Excel and can pull from databases, APIs, CSVs, etc. There's no hosting infra and no new monthly fee as I already had the Excel license.
Another nice thing about spreadsheets is that today, they're multi-user and real-time collaborative. You can send someone a link and both edit an Excel or Google Docs spreadsheet in the browser with very low ceremony. And if they're on a power user, they can modify the formulas themselves. That's a bad thing for some use cases but a truly great thing for others.
The ubiquity, the local-first option, the tightly coupled GUI, the widely known syntax...those things make spreadsheets very attractive for certain types of projects.
For others, building an app is the right answer. They both have a place.
Making a spreadsheet that does a variety of calculations, displays graphs, live updates, is share-able, editable via web and mobile, can be embedded in technical documents and presentations is all free with a spreadsheet. Your comment trying to address the speed argument, replacing with a "python REPL" is difficult to take seriously. Spreadsheets are order of magnitude faster, and that speed advantage scales from the simplest of spreadsheets to the most complex (i.e., just summing a column of data will be maybe 10 times faster in a spreadsheet than a python REPL [although both are trivially fast for this use case], and doing all of the above listed features would be months to program relative to free for the spreadsheet).
"If the only tool you have is a hammer, it is tempting to treat everything as if it were a nail." [1]
While you can solve a lot of problems with code, code might not be the best way to solve some problems.
I want to type in some data, mix it up, explore, maybe make a quick graph, get some stats, decide if I need to make more calculations. By the time you decide on what tools to use and run your pip install or whatever, I'd be long done.
Conversely, I have seen spreadsheets used for a lot of things that they shouldn't be.
i am able to program but hell no i will start to crunch numbers programmatically unless it's something a basic spreadsheet can't do. i use spreadsheets exactly because i don't need to code and create something from scratch.
but while this is not for me (no interest in learning vim), i'm pretty sure many other people will find this useful
VisiCalc - the first spreadsheet - was entirely text based and people found it useful enough that it exploded in popularity and was very successful on the Apple ][ until the advent of the IBM PC when Lotus 1-2-3 came and ate its lunch.
I'm not a spreadsheet guy, so I can't say how "good" they are, but Emacs has a few. Of course org-mode can do some of it (what can't org-mode do?), but in my experience it bogs down with larger datasets. Simple Emacs Speadsheet has been around a while and comes built-in these days, but I haven't tried it.
One nice thing is that Emacs has calc-mode built in that gives you all kinds of advanced math capability you can use. The tables in org-mode support this directly, but since calc has a Lisp interface you can use it pretty much anywhere.
This has been posted several times on HN, but besides being awesome, this project should be better funded. Please read the README on Github and sponsor it on patreon.
kkukshtel|1 year ago
https://www.visidata.org/
It's saved my ass on multiple occasions for data wrangling and munging and highly recommend people use it in their own toolkit.
somat|1 year ago
I am not fond of the the usual spreadsheet data model. "It's a big bag of cell" does not fill me with joy. And upon a bit of reflection I think it is the rows, I really hate how easy it is for rows to get out of sync. All I really want is row security.* And this is what visidata brings to the table.
* Relational databases provide this in spades. and in truth most of my spreadsheets have been replaced by them(I maintain a local postgres server on my desktop for all the small random prototype junk you would usually do in a spreadsheet using visidata as a pager) And while the database is great for analysis, random data entry sort of sucks. There are some great tools out there for this. I don't tend to use them, mainly because psql is always there, so I just sort of grumble when I have to do random entry without trying to fix anything. Why postgres instead of sqlite? I like the types and functions better.
Gormo|1 year ago
fuzztester|1 year ago
https://youtu.be/N1CBDTgGtOU
Submitted it here in case people want to comment about the video:
https://news.ycombinator.com/item?id=40885556
msla|1 year ago
https://siag.nu/siag/
It has support for the Scheme programming language, MySQL, sending email (was jwz on this project?), and being part of a whole office suite.
SIAG Office:
http://siag.nu/index.shtml
(I'm kinda surprised. I remember when this was just that odd little program that shipped with Damn Small Linux.)
It can even load multiple file formats, including LaTeX, troff, and HTML tables:
https://siag.nu/siag/fileformats.html
packetlost|1 year ago
knuckleheads|1 year ago
djha-skin|1 year ago
The terminal tools have gotten so much better in the last few years. There's a real Renaissance happening.
llm_trw|1 year ago
Now we are doing the same thing to the terminal.
I'd rather have a poor UI that works than a flashy one that breaks, which is what we'll get in 10 years. Just like with regular UIs.
ikari_pl|1 year ago
meindnoch|1 year ago
bbor|1 year ago
Because really, do you want all of vim in sheets, or just navigation (`i/h/j/k/gg/G/^u/^d`) and selection (`v/V`)? It has some other basic stuff, like `dd` and `o/O`, but otherwise conflicts with browser and Google functionality keep me away.
jerpint|1 year ago
khimaros|1 year ago
VagabundoP|1 year ago
ericpruitt|1 year ago
pridkett|1 year ago
If you’re looking just for spreadsheets, Travis Ormandy somehow managed to get Lotus 1-2-3 to run on Linux a few years ago[1]. It’s a neat comparison point.
[0] https://www.visidata.org/ [1] https://lock.cmpxchg8b.com/linux123.html
raingrove|1 year ago
5-|1 year ago
that, and there aren't any "ui/ux designers" specialising in cursor-addressing uis.
kazinator|1 year ago
It sounds like "scim" is to "sc" vaguely like "vim" is to "vi": new program with more features cloning/imitating ancient program.
"vi" was written by Bill Joy in 1979.
"sc" by James Gosling in 1981.
sc-im claims to be based on "sc".
It's a direct lineage unrelated to GUI spreadsheets.
mytec|1 year ago
https://forum.winworldpc.com/discussion/7590/software-spotli...
smabie|1 year ago
fbn79|1 year ago
k2enemy|1 year ago
asdefghyk|1 year ago
skywal_l|1 year ago
PS: Jeez, so much ads in Byte Magazine! Or is it because I haven't open a magazine in a couple of decades and forgot how cluttered they were??
[0] https://en.wikipedia.org/wiki/Turbo_Vision
[1] https://github.com/magiblot/tvision
asdefghyk|1 year ago
Joker_vD|1 year ago
eterps|1 year ago
In a spreadsheet, I'm used to being able to move around with arrow keys and start typing immediately. Using SCIM, it feels like I'm constantly hitting a wall.
Despite that, I think the idea of a spreadsheet as a TUI is really great.
atlintots|1 year ago
croemer|1 year ago
trollbridge|1 year ago
hello_computer|1 year ago
mgerdts|1 year ago
> sc-im is based on sc, whose original authors are James Gosling and Mark Weiser, and mods were later added by Chuck Martin.
sylware|1 year ago
Plain and simple C, etc. I would have liked a one compilation unit with proper preprocessor namespaces/name mangling, that to be picky.
purple-leafy|1 year ago
A far cry from the world of the GUI, but a welcome world
executesorder66|1 year ago
In my opinion: if you can use vim, you can probably code, or at least figure it out without too much trouble. If you can code, then you don't need a spreadsheet. You can just write a program to crunch the numbers, or produce a report etc.
Excel is so popular, because it is a way for non-coders to crunch a bunch of numbers in a relatively easy way. And the best way to get the answers that they are getting out of the spreadsheet is to write code. But because they can't code, they have to use a spreadsheet.
If there is a use case for spreadsheets that is not better served by some real code, I'm interested to hear what it is.
You could also make the "speed" argument (just a quick calculation) for spreadsheets, but in that case, I find something like a python REPL just as quick, and still better anyway.
tannhaeuser|1 year ago
While vi might be a code editor first and foremost, not all vi users are coders. There are copy writers, academic and literature, having a need for fast and focussed touch typing (George R. R. Martin comes to mind as prominent WordStar user). The entire point of SGML/XML/HTML markup is to be able to create rich text documents without binary formats and special editors; this is also the case with Wiki syntaxes like markdown, which have been around since long before John Gruber's original Markdown.PL and are directly supported as a shortref customisation in SGML, from 1986, BTW.
Conversely, even if you are a coder, classic spreadsheets are extremely useful for any type of ad-hoc reproducible calculation (such as for taxes or other personal or business finance stuff). You really should check out spreadsheets if you haven't already; the point is that you can cross-reference cell values and copy/paste with relative cell positions to create large calculation tables/matrices, then update base values and perform "what-if" analyses, etc. etc. Using cell formulas is more like a logical programming language environment. I've used it for all kinds of reports apart from financials (benchmarks, construction/project planning, even a Tic Tac Toe game in school out of boredom).
otikik|1 year ago
> If there is a use case for spreadsheets that is not better served by some real code, I'm interested to hear what it is.
Sharing information with non-coders could be an obvious one. I could have done a database with my wife's sewing patterns collection, of which she has ~300. Instead, I did a spreadsheet in google docs, which she's very familiar with. Told her how to enter data there (4 fields, name, file, tags and picture) and there's a couple tabs that allow her to filter things out, etc. Then she can do whatever she wants with it, like using conditional formatting to make dress patterns red. It was done in 2-3 hours, and she got exactly what she wanted.
I worked in a place where both the input and output was spreadsheets, and the users were spreadsheet users. We did implement a database for this particular one for the heavy algorithmic part, but a lot of the business logic (e.g. initial data validation, final presentation of the results) lived on the spreadsheets themselves.
Another interesting one is data-to-visual time. Unless you happen to be proficient in a particular area of programming (e.g. front programming with proficiency in something like D3, or R programmer) getting decent graphs out of data is a chore when going the programming route. With spreadsheets, you put the columns and get the graphs essentially for free.
To me spreadsheets are just another tool in the toolbox; they are appropriate for some tasks. They can definitely be misused and abused. Knowing which occasion is which is where experience comes in.
mharig|1 year ago
And, btw, if you search for "distraction free writing",you will find that even some non-coders use vim.
brushfoot|1 year ago
Think of spreadsheets as a convention-over-configuration low-code environment with a tightly coupled GUI for spinning up run-almost-anywhere apps that non-coders can modify. One of the few low-code environments that I actually like.
I'm a solopreneur whose SaaS product I coded from scratch. I love GPPLs, but I also create spreadsheets all the time.
Sometimes that's because of the stage of an idea: There's a new process you've discovered you need, but you don't have time to invest in building/buying/learning a tailor-made solution.
A case in point is a business overview dashboard I built to keep an eye on the metrics I care about. It pulls data from disparate sources using Power Query, which is built into Excel and can pull from databases, APIs, CSVs, etc. There's no hosting infra and no new monthly fee as I already had the Excel license.
Another nice thing about spreadsheets is that today, they're multi-user and real-time collaborative. You can send someone a link and both edit an Excel or Google Docs spreadsheet in the browser with very low ceremony. And if they're on a power user, they can modify the formulas themselves. That's a bad thing for some use cases but a truly great thing for others.
The ubiquity, the local-first option, the tightly coupled GUI, the widely known syntax...those things make spreadsheets very attractive for certain types of projects.
For others, building an app is the right answer. They both have a place.
robenkleene|1 year ago
gapan|1 year ago
While you can solve a lot of problems with code, code might not be the best way to solve some problems.
I want to type in some data, mix it up, explore, maybe make a quick graph, get some stats, decide if I need to make more calculations. By the time you decide on what tools to use and run your pip install or whatever, I'd be long done.
Conversely, I have seen spreadsheets used for a lot of things that they shouldn't be.
[1] https://en.wikipedia.org/wiki/Law_of_the_instrument
asutekku|1 year ago
but while this is not for me (no interest in learning vim), i'm pretty sure many other people will find this useful
cyanydeez|1 year ago
This is a poor man's excuse for not liking excel.
zik|1 year ago
Lotus was also text based.
broodbucket|1 year ago
qwertyuiop_|1 year ago
happysadpanda2|1 year ago
https://news.ycombinator.com/item?id=29241136
agumonkey|1 year ago
pentaphobe|1 year ago
But this is pretty cool
radarsat1|1 year ago
spauldo|1 year ago
One nice thing is that Emacs has calc-mode built in that gives you all kinds of advanced math capability you can use. The tables in org-mode support this directly, but since calc has a Lisp interface you can use it pretty much anywhere.
helmette|1 year ago
lkdfjlkdfjlg|1 year ago
constantcrying|1 year ago
It is more keyboard driven than Excel and felt a bit more "productive", far less focus on designing the spreadsheet.
You use Excel because you have to, as part of your job. But I used this for some smaller things and it worked reasonably well.
FerretFred|1 year ago
opengears|1 year ago
29athrowaway|1 year ago
nine_k|1 year ago
And supports plugins in a much nicer language than dBase.
Now if it only supported easy form and grid-based UI builder, it would also be comparable to Clipper :)
tonetheman|1 year ago
[deleted]
conception|1 year ago
Might affect searchability.
glandium|1 year ago
dmix|1 year ago
https://wiki.gentoo.org/wiki/Sc-im
unknown|1 year ago
[deleted]
unknown|1 year ago
[deleted]
opengears|1 year ago
unknown|1 year ago
[deleted]
etx|1 year ago
[deleted]
AbraKdabra|1 year ago
[deleted]
toenail|1 year ago
layer8|1 year ago
teo_zero|1 year ago