19 replies
22h30m
Pretty cool! It's kinda amusing that we've gone from TUI (VisiCalc/Lotus 1-2-3) to GUI (Excel), and back to TUI though.
17 replies
8h56m
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.
4 replies
6h33m
That's wrong in more than one way IMO.
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).
2 replies
6h22m
I don't disagree with your first paragraph, but I don't think it is relevant to what I was saying.
Conversely, even if you are a coder, classic spreadsheets are extremely useful for any type of ad-hoc reproducible calculation
Again, I still feel like code is the ideal solution to "ad-hoc reproducible calculations"
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.
I still don't see how you can't do that with code, nor what the spreadsheet is doing that code can't.
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).
Sure. It has been proven that excel is Turing complete. But I'd rather use a programming language (a tool that was literally designed for the purpose of writing code), than a clunky spreadsheet. Both can get the job done, I never denied that. But I still don't see the value that the spreadsheet brings over custom code written to solve the exact same problem.
0 replies
2h1m
I'd love to hear what specifically makes you call spreadsheets "clunky"? (Personally I find spreadsheets to be quite elegant, a table adapts easily to WIMP [https://en.wikipedia.org/wiki/WIMP_(computing)]. E.g., in contrast to say the Bézier curve interface in Illustrator, which I wouldn't ask for explanation in being called clunky, because drawing curves does not adapt easily to WIMP for example.)
0 replies
5h51m
Again, I still feel like code is the ideal solution to "ad-hoc reproducible calculations"
I am a developer and I do my personal budgeting on a spreadsheet. It was easier to setup and maintain, and follows my process better than the personal finance software I have used before. Could I have made a little program for this? Sure, but it would be time consuming and I have better projects to spend my time on.
0 replies
5h20m
Let me tell you the story of how i came to love and use sc-im instead of my own solution.
Multi-country taxes are too much fun. Every dollar/GBP amount needs to be converted to the other currency for taxes in that country.
I originally did this in libre office but I got annoyed at it and wrote a markdown pipeline to produce PDFs for my accountants.
I would do data entry in CSV and wrote a CSV to markdown converter. Along the way I wrote a simple CSV formula language with just a couple of functions that would do column level operations e.g. =MUL(C, E) to multiply columns C and E.
This worked pretty well, and I could make a small directory of sorted markdown files to assemble, and a Makefile to transform the CSV+formula files to flat CSVs.
But CSV input was kind of annoying and my formula language wasn't easy to extend, or very nice. So I jumped at sc-im which can directly output markdown tables.
Anyway, I highly recommend sc-im, the .sc files are a fine replacement for my custom solution and I haven't looked back (and taxes are coming again soon!)
1 replies
7h37m
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.
0 replies
6h11m
Sharing information with non-coders could be an obvious one.
You can do the exact same thing with code. You can still output reports and diagrams, and literally anything the "customer/user" wants.
I could have done a database with my wife's sewing patterns collection...
Your example is a good one. I didn't think of images.
It was done in 2-3 hours, and she got exactly what she wanted.
Fair enough. A spreadsheet was probably the right tool for the job in this case. But if she ever wanted more features, and the complexity increased, I don't know if it still would be.
I worked in a place where both the input and output was spreadsheets, and the users were spreadsheet users.
Okay, but should they have been? Would custom software not have been the better solution?
a lot of the business logic (e.g. initial data validation, final presentation of the results) lived on the spreadsheets themselves.
When I think of "business logic", "data validation", and "final presentation", a spreadsheet is one of the last tools I'd reach for.
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.
I also disagree with this. I am very much a back-end developer. But using something like GNUplot or a library like matplotlib is pretty easy for outputting a nice looking graph from tabular data.
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.
I agree with this. But I guess the difference is I can think of almost no circumstances where it's the better tool for a coder.
1 replies
6h53m
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.
0 replies
6h30m
That's a good point about the data entry.
I've never really had a problem entering data into CSV file or database, but I will concede that it is even easier to enter the data via a spreadsheet.
However, I still think custom software (with proper UI for input if necessary) is the better way of dealing with the actual solution that a spreadsheet is ultimately trying to solve.
1 replies
7h21m
Spreadsheets have a much wider acceptance and lower threshold to pure data.
This is a poor man's excuse for not liking excel.
0 replies
6h35m
Spreadsheets have a much wider acceptance
I know. Most people don't know how to code, thus they are forced to use spreadsheets as I already mentioned.
spreadsheets have a lower threshold to pure data
I'm not sure what you mean here. That it is easier for the average human to work with data using a spreadsheet compared to code?
Sure, as already mentioned. Most people don't know how to code.
But what I'm getting at is that a spreadsheet is the poor mans code.
And if you audience is coders (not the whole world), then why go for the worse option?
0 replies
7h36m
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.
Lotus was also text based.
0 replies
2h47m
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).
0 replies
5h56m
"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.
0 replies
5h18m
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.
0 replies
8h37m
I would nominally agree but plenty of people seem to use and appreciate this so who am I to judge.
0 replies
7h37m
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
16 replies
23h24m
I think it looks gorgeous, but I'm skeptical that it's actually more efficient than just using excel.
12 replies
23h19m
show me how you start excel in your terminal
5 replies
23h17m
For me spreadsheets are most useful when shared. My biggest objection - can I share with e.g. google sheets or office 365?
I think it's neat for terminal usage, though.
Other problem: I can vim but I prefer the emacs keybindings.
1 replies
23h10m
You can share with git. But obviously this is no real replacement for cloud based multi user spread sheet software.
To be honest I also think that if you are making heavy use of cloud based spread sheet software you have a 100% chance of being a drain on your organization and society as a whole, so I can't really count those missing features as a big downside.
0 replies
20h49m
To be honest I also think that if you are making heavy use of cloud based spread sheet software you have a 100% chance of being a drain on your organization and society as a whole
How about for just personal (family/friends) usage?
I would tend to agree spreadsheets are a crutch in larger orgs, however they're best deployed as a prototype tool IMO.
There's plenty of room for > 1 and < 5 (write-access) person operations where cloud based xlsx sharing just makes far more sense than some expensive/excessive enterprise tools.
1 replies
23h12m
I suppose you could share using tmux or screen.
0 replies
20h48m
And my next question would be can this software handle concurrent writes?
If it could, that'd be an excellent solution.
0 replies
22h52m
It appears to support XLSX, so for certain level of sharing it should work.
2 replies
23h18m
That's.... my point. I'm skeptical that you'd be more efficient by doing spreadsheet operations on your terminal vs just using excel on your non-terminal.
1 replies
19h31m
Imagine having the ability doing your budgetting spreadsheet over SSH, okay never mind ...
0 replies
7h2m
Why would I choose to do such a basic task over SSH? I do all "office-type" tasks locally. Adding a network here is just over complicating.
2 replies
22h59m
'
open /Applications/Microsoft Excel.app/0 replies
20h15m
Hmmm:
The files /Applications/Microsoft and /Users/lsllc/Excel.app do not exist.
/s
[0] To escape the space, or you could quote the entire argument to `open`
0 replies
10h18m
More robust:
open -b com.Microsoft.Excel
Disadvantage: autocomplete doesn’t work on that in the terminal.
1 replies
23h13m
but I'm skeptical that it's actually more efficient than just using excel.
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.
0 replies
23h11m
Lotus 1-2-3 was originally a screen-based, keyboard driven application.
0 replies
22h47m
I used it on my Raspberry Pi Zero "TravelPi" project which was TUI-based. No way could I get Excel on there :)
7 replies
20h30m
tried this out a while back and ultimately settled on visidata instead https://github.com/saulpw/visidata
4 replies
19h49m
Could you explain what made you prefer visidata over SCIM?
1 replies
18h18m
fast loading of massive datasets and built-in support for SQLite tables. i also found the interaction to be more intuitive, which is important for a tool i pick up sporadically.
0 replies
8h25m
That's really neat, I've been looking exactly for a spreadsheet TUI to browse and edit SQLite dbs. Cheers!
0 replies
9h13m
Probably some of the functionality showed off here, https://www.youtube.com/watch?v=N1CBDTgGtOU , besides the handling of large amounts of data.
0 replies
19h27m
for one i work with GB large files and vd instantly opens them. SCIM it took a lot of painful seconds to open 14mb file
1 replies
6h26m
Just tried it and Visidata is awesome. Just loading SQLite dbs is a killer feature with the TUI.
0 replies
3h48m
Visidata blows everything else in this category out of the water. I can open a table on a remote Postgres DB, use a regex filter to select the records I want, then do an outer join to a local CSV, all with just a few keystrokes.
7 replies
15h5m
Where have you been all my life. This fills such a hole in the market -- a Vim-like terminal spreadsheet tool.
The terminal tools have gotten so much better in the last few years. There's a real Renaissance happening.
3 replies
8h2m
It's only because you can't put Electron apps in the terminal (yet).
0 replies
5h7m
But you can already put React in the terminal with react-curse.
0 replies
7h43m
though with brow.sh ... :D
0 replies
4h44m
No, PLEASE DON'T!
1 replies
11h23m
Microsoft Multiplan for CP/M is the tool for you and only needs 46, maybe 60kB of free memory!
0 replies
3h37m
There is a Multiplan for DOS either. The Multiplan [1] page has more information:
0 replies
12h29m
The terminal has gotten good because the GUIs have gotten useless.
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.
5 replies
4h21m
For something similar but different, I highly recommend people check out Visidata:
It's saved my ass on multiple occasions for data wrangling and munging and highly recommend people use it in their own toolkit.
0 replies
42m
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.
0 replies
2h47m
VisiData is the best! Saul (the creator) is also a phenomenal dev
0 replies
26m
There's also Scheme In A Grid (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:
(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:
0 replies
3h31m
I've been trying to remember the name for this for weeks now, thank you for mentioning it!
0 replies
4h12m
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.
4 replies
22h25m
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.
1 replies
22h4m
What could be a more Vim-like experience than feeling like you're constantly hitting a wall when first learning? :)
0 replies
21h58m
True, but in my case I think it isn't enough of a Vim-like experience. In that case I would have expected modes I could stay in for longer than a single cell entry.
It would be fine if I'm in insert/edit mode and I can move around entering values in several cells and then press escape to exit that mode.
The reason I think TUIs are attractive to use is because they're more efficient to use. But this one doesn't feel more efficient to use than its GUI counterparts.
0 replies
19h34m
Whilst this is a neat project, it would seem the best way to get a Vim-like spreadsheet would be to build something actually in Vim.
0 replies
21h30m
My expectation would be that you have to enter insert mode first before you can type, no?
2 replies
11h48m
Are there any good emacs modes for spreadsheeting?
0 replies
33m
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.
0 replies
10h55m
Org mode.
2 replies
20h30m
Btw SCIM is the name of the standard for cross-domain identity management. https://en.m.wikipedia.org/wiki/System_for_Cross-domain_Iden...
Might affect searchability.
0 replies
19h29m
Also, of an input method. https://en.wikipedia.org/wiki/Smart_Common_Input_Method
0 replies
17h9m
It's technically `sc-im` not SCIM, because it forked a spreadsheet program from 1981 called `sc`
1 replies
22h58m
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.
0 replies
19h46m
Awesome, thanks for sharing
1 replies
22h31m
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 ....
0 replies
12h52m
A little bit like Turbo Vision[0] then. Turbo vision which has now a free port to modern terminal btw [1].
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??
1 replies
23h4m
Does it have more features than dBase IV, Quattro Pro?
0 replies
19h5m
I suppose it can edit much larger files, and supports vi navigation and editing commands.
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 :)
0 replies
21h6m
Quite cool.
Plain and simple C, etc. I would have liked a one compilation unit with proper preprocessor namespaces/name mangling, that to be picky.
0 replies
16h50m
Looks like good old dBase https://m.youtube.com/watch?v=Pr1mASV2iTg&pp=ygUHZGJhc2UgNA%...
0 replies
13h38m
That’s so cool that people are making projects like this, making money off it.
A far cry from the world of the GUI, but a welcome world
0 replies
4h16m
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.
[0] https://www.visidata.org/ [1] https://lock.cmpxchg8b.com/linux123.html
0 replies
10h16m
Occasionally I find myself disliking projects simply because they overload existing acronyms..
But this is pretty cool
0 replies
23h24m
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.
0 replies
18h58m
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.
0 replies
5h25m
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.
0 replies
12h59m
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.
0 replies
9h35m
I've long been looking for such a thing. I don't want to fire panda, nor emacs org-table, just have a quick way to label, aggregate datatables.
0 replies
8h53m
Is there an ed-like spreadsheet? I don't quite like looking at the data I am working with, it's a bit distracting, you see (pun intended).
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.
What do you mean precisely by "character addressing UI"? I can infer approximately what you mean, but I had never heard that phrase before and could not Google it, so was wondering how precisely you define that as presumably slightly distinct from other more common terms for text mode applications.
thanks! i meant 'cursor-addressing', to avoid the ambiguous term 'tui', which usually (and per https://en.wikipedia.org/wiki/Text-based_user_interface) means cursor-addressing, but nominally also includes actual text-based user interfaces, as seen in e.g. the traditional unix utilities.
You still didnt define what "cursor addressing" means. Its not a common term to use for these UIs and doesnt seem to get to the crux of what separates a typical GUI from these.
For me, the crucial difference is that they're usable over ssh and tmux, not the type of cursor they have (if any).
I've always seen CLI used for unix style utilities and TUI used for cursor-addressing/ncurses style interfaces fwiw.
I take it you haven't heard about: https://charm.sh/
Interesting that Website reliably crashes mobile Firefox (nightly and release) and brave for me.
Works fine on my Pixel 7a using the release version of Firefox (I won't dare touch Brave), fwiw.
Depends where you look.
https://davideellis.wordpress.com/2012/08/31/ibm-tivoli-moni...
Not really. There is an ancient curses-based spreadsheet program called "sc" (spreadsheet calculator).
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.
Gosling wrote sc? I had no idea. I was an scim user before moving to visidata like another poster mentioned, so I kinda-sorta feel like an sc user.
For those who don't know, James Gosling invented a popular VM-based "write once, test everywhere" programming language named after a tree. Then named after a coffee.
Gosling also invented a structural macro processor for C, in 1989.
Ace: a syntax-driven C preprocessor: https://swtch.com/gosling89ace.pdf
In 1981, Gosling Emacs: https://en.wikipedia.org/wiki/Gosling_Emacs
Richard Stallman used Gosling Emacs as the starting code for GNU Emacs.
For those who don't know, and don't want to have to go off and search to understand the cryptic comment... He's talking about Java. Which in an earlier iteration was known as Oak.
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
If you can find a way to make touch-friendly interfaces useful on desktop devices with a large screen and a keyboard maybe then they'll take off.
Better yet, make all user interfaces the same as a toaster. Everyone can use a toaster. Bread goes in, push the lever. One universal way of thinking for everyone and everything. No domination by the tyranny of choice.
You might have not seen different kind of tosters.
And if that requires any tradeoffs like it did for GUIs (no hover, no small elements) it'll end up getting dumbed down for mobile like GUIs did.
No one has gone back for real spreadsheet work tho
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.
https://forum.winworldpc.com/discussion/7590/software-spotli...