[HN Gopher] SCIM: Ncurses based, Vim-like spreadsheet
___________________________________________________________________
SCIM: Ncurses based, Vim-like spreadsheet
Author : emersonrsantos
Score : 391 points
Date : 2024-07-04 18:04 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| opengears wrote:
| 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.
| lkdfjlkdfjlg wrote:
| I think it looks gorgeous, but I'm skeptical that it's actually
| more efficient than just using excel.
| opengears wrote:
| show me how you start excel in your terminal
| lkdfjlkdfjlg wrote:
| 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.
| teleforce wrote:
| Imagine having the ability doing your budgetting
| spreadsheet over SSH, okay never mind ...
| lkdfjlkdfjlg wrote:
| 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.
| smaudet wrote:
| 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.
| SoftTalker wrote:
| I suppose you could share using tmux or screen.
| smaudet wrote:
| And my next question would be can this software handle
| concurrent writes?
|
| If it could, that'd be an excellent solution.
| constantcrying wrote:
| 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.
| smaudet wrote:
| > 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.
| p_l wrote:
| It appears to support XLSX, so for certain level of sharing
| it should work.
| fragmede wrote:
| ' open /Applications/Microsoft Excel.app/
| lsllc wrote:
| Hmmm: The files /Applications/Microsoft
| and /Users/lsllc/Excel.app do not exist.
|
| Missing a backslash! [0] ... how quaintly Microsoft!
|
| /s
|
| [0] To escape the space, or you could quote the entire
| argument to `open`
| Someone wrote:
| More robust: open -b com.Microsoft.Excel
|
| That will open it even if it has a different name or is in
| a different directory.
|
| Disadvantage: autocomplete doesn't work on that in the
| terminal.
| constantcrying wrote:
| >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.
| SoftTalker wrote:
| Lotus 1-2-3 was originally a screen-based, keyboard driven
| application.
| FerretFred wrote:
| I used it on my Raspberry Pi Zero "TravelPi" project which was
| TUI-based. No way could I get Excel on there :)
| 29athrowaway wrote:
| Does it have more features than dBase IV, Quattro Pro?
| nine_k wrote:
| 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 :)
| bbor wrote:
| 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.
| jerpint wrote:
| Awesome, thanks for sharing
| asdefghyk wrote:
| 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 ....
| skywal_l wrote:
| 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??
|
| [0] https://en.wikipedia.org/wiki/Turbo_Vision
|
| [1] https://github.com/magiblot/tvision
| raingrove wrote:
| 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.
| 5- wrote:
| 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.
| galdosdi wrote:
| 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.
| 5- wrote:
| 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.
| Shared404 wrote:
| I've always seen CLI used for unix style utilities and
| TUI used for cursor-addressing/ncurses style interfaces
| fwiw.
| TickleSteve wrote:
| 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).
| ncruces wrote:
| I take it you haven't heard about: https://charm.sh/
| cycomanic wrote:
| Interesting that Website reliably crashes mobile Firefox
| (nightly and release) and brave for me.
| thegeekpirate wrote:
| Works fine on my Pixel 7a using the release version of
| Firefox (I won't dare touch Brave), fwiw.
| akira2501 wrote:
| > and there aren't any "ui/ux designers" specialising in
| cursor-addressing uis.
|
| Depends where you look.
|
| https://davideellis.wordpress.com/2012/08/31/ibm-tivoli-
| moni...
| kazinator wrote:
| 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.
| dotancohen wrote:
| 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.
| kazinator wrote:
| 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.
| FearNotDaniel wrote:
| 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.
| mytec wrote:
| 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...
| smabie wrote:
| No one has gone back for real spreadsheet work tho
| fbn79 wrote:
| 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
| IsTom wrote:
| > If you find a way to make them usable on mobile
|
| 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.
| bregma wrote:
| 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.
| playingalong wrote:
| You might have not seen different kind of tosters.
| eterps wrote:
| 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.
| atlintots wrote:
| What could be a more Vim-like experience than feeling like
| you're constantly hitting a wall when first learning? :)
| eterps wrote:
| 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.
| croemer wrote:
| My expectation would be that you have to enter insert mode
| first before you can type, no?
| trollbridge wrote:
| 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.
| sylware wrote:
| 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.
| conception wrote:
| 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.
| glandium wrote:
| Also, of an input method.
| https://en.wikipedia.org/wiki/Smart_Common_Input_Method
| dmix wrote:
| It's technically `sc-im` not SCIM, because it forked a
| spreadsheet program from 1981 called `sc`
|
| https://wiki.gentoo.org/wiki/Sc-im
| khimaros wrote:
| tried this out a while back and ultimately settled on visidata
| instead https://github.com/saulpw/visidata
| ericpruitt wrote:
| Could you explain what made you prefer visidata over SCIM?
| Exuma wrote:
| 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
| khimaros wrote:
| 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.
| steinuil wrote:
| That's really neat, I've been looking exactly for a
| spreadsheet TUI to browse and edit SQLite dbs. Cheers!
| cess11 wrote:
| Probably some of the functionality showed off here,
| https://www.youtube.com/watch?v=N1CBDTgGtOU , besides the
| handling of large amounts of data.
| VagabundoP wrote:
| Just tried it and Visidata is awesome. Just loading SQLite dbs
| is a killer feature with the TUI.
| Gormo wrote:
| 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.
| mgerdts wrote:
| 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.
| qwertyuiop_ wrote:
| Looks like good old dBase
| https://m.youtube.com/watch?v=Pr1mASV2iTg&pp=ygUHZGJhc2UgNA%...
| djha-skin wrote:
| 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.
| llm_trw wrote:
| 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.
| ikari_pl wrote:
| Microsoft Multiplan for CP/M is the tool for you and only needs
| 46, maybe 60kB of free memory!
| wslh wrote:
| There is a Multiplan for DOS either. The Multiplan [1] page
| has more information:
|
| [1] https://en.wikipedia.org/wiki/Multiplan
| fuzztester wrote:
| Shh! Don't remind Bill Gates of his famous last words!
|
| https://www.google.com/search?q=640kb+ought+to+be+enough+for.
| ..
| meindnoch wrote:
| It's only because you can't put Electron apps in the terminal
| (yet).
| ikari_pl wrote:
| though with brow.sh ... :D
| sesm wrote:
| But you can already put React in the terminal with react-
| curse.
| meindnoch wrote:
| React-curse? How fitting.
| gespadas wrote:
| No, PLEASE DON'T!
| fuzztester wrote:
| Don't worry. The word on the street is that a red-hot startup
| is shortly launching a terminal with a petabyte of memory
| attached to it.
|
| (They patented an innovation called hardware attached to
| software, instead of the traditional software attached to
| hardware.)
|
| That should easily suffice for many instances of bloatware,
| er, Electron apps running in tmux tabs.
|
| Hybrid apps FTW!
| purple-leafy wrote:
| 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
| hello_computer wrote:
| 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.
| radarsat1 wrote:
| Are there any good emacs modes for spreadsheeting?
| helmette wrote:
| Org mode.
| spauldo wrote:
| 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.
| pentaphobe wrote:
| Occasionally I find myself disliking projects simply because they
| overload existing acronyms..
|
| But this is pretty cool
| agumonkey wrote:
| 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.
| executesorder66 wrote:
| 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.
| broodbucket wrote:
| I would nominally agree but plenty of people seem to use and
| appreciate this so who am I to judge.
| asutekku wrote:
| 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
| otikik wrote:
| 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.
| executesorder66 wrote:
| > 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.
| zik wrote:
| 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.
| cyanydeez wrote:
| Spreadsheets have a much wider acceptance and lower threshold
| to pure data.
|
| This is a poor man's excuse for not liking excel.
| executesorder66 wrote:
| > 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?
| mharig wrote:
| 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.
| executesorder66 wrote:
| 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.
| dredmorbius wrote:
| Unless you're a geneticist:
|
| "Scientists rename human genes to stop Microsoft Excel from
| misreading them as dates" (2023)
| <https://www.theverge.com/2020/8/6/21355674/human-genes-
| renam...>
|
| Or anyone else for whom Excel's automatic data-munging
| "features" are a concern.
| tannhaeuser wrote:
| 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).
| executesorder66 wrote:
| 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.
| pmelendez wrote:
| > 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.
| robenkleene wrote:
| 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 Bezier 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.)
| dmwilcox wrote:
| 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!)
| gapan wrote:
| "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.
|
| [1] https://en.wikipedia.org/wiki/Law_of_the_instrument
| brushfoot wrote:
| > 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.
| robenkleene wrote:
| 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).
| Joker_vD wrote:
| 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).
| k2enemy wrote:
| 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.
| kkukshtel wrote:
| For something similar but different, I highly recommend people
| check out Visidata:
|
| 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.
| Gormo wrote:
| 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.
| knuckleheads wrote:
| I've been trying to remember the name for this for weeks now,
| thank you for mentioning it!
| packetlost wrote:
| VisiData is the best! Saul (the creator) is also a phenomenal
| dev
| somat wrote:
| 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.
| cykros wrote:
| It's all about picking the right tool for the job. I don't
| see easily constructing a Discounted Cash Flow model in a
| relational database making a ton of sense. Sure, you could
| have the data in one, and use a php script to handle the
| modeling, and output it on a webpage, but the reality is, a
| spreadsheet just does it a lot easier, and is what most
| people would want.
|
| For handling structured data, spreadsheets can do it, but
| they're not always going to be the best tool for the job, as
| they do a lot of other things, too, which means if you're not
| careful, your data will lose its appropriate structure.
| msla wrote:
| There's also Scheme In A Grid (SIAG):
|
| 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
| fuzztester wrote:
| VisiData Lightning Demo at PyCascades 2018:
|
| https://youtu.be/N1CBDTgGtOU
|
| Submitted it here in case people want to comment about the
| video:
|
| https://news.ycombinator.com/item?id=40885556
| pridkett wrote:
| 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
___________________________________________________________________
(page generated 2024-07-05 23:02 UTC)