Very cool article!<p>I also implemented a spreadsheet last year [0] in pure TypeScript, with the fun twist that formulas also update backwards. While the backwards root finding algorithm was challenging, I also found it incredibly humbling to discover how much complexity there is in the UX of the simple spreadsheet interface. Handling selection states, reactive updates, detecting cycles of dependency and gracefully recovering from them is a massive state machine programming challenge! Very fun project with a lot of depth!<p>I myself didn't hand roll my own parser but used Ohm-js [1] which I highly recommend if you want to parse a custom language in Javascript or TypeScript.<p>> One way of doing this is to keep track of all dependencies between the cells and trigger updates when necessary. Maintaining a dependency graph would give us the most efficient updates, but it’s often an overkill for a spreadsheet.<p>On that subject, figuring out the efficient way to do it is also a large engineering challenge, and is definitely not overkill but absolutely required for a modern spreadsheet implementation. There is a good description of how Excel does it in this famous paper "Build systems a la carte" paper, which interestingly takes on a spreadsheet as a build system [2].<p>[0] <a href="https://victorpoughon.github.io/bidicalc/" rel="nofollow">https://victorpoughon.github.io/bidicalc/</a><p>[1] <a href="https://ohmjs.org/" rel="nofollow">https://ohmjs.org/</a><p>[2] <a href="https://www.microsoft.com/en-us/research/wp-content/uploads/2018/03/build-systems.pdf" rel="nofollow">https://www.microsoft.com/en-us/research/wp-content/uploads/...</a>
Reminds me of spreadsheet-fortran (<a href="https://github.com/lwsinclair/spreadsheet-fortran" rel="nofollow">https://github.com/lwsinclair/spreadsheet-fortran</a>), a project creating a VisiCalc lookalike in FORTRAN 66, which even runs on a PDP-11.
Quote:<p><pre><code> #define MAXIN 128 // max cell input length
enum { EMPTY, NUM, LABEL, FORMULA }; // cell types
struct cell {
int type;
float val;
char text[MAXIN]; // raw user input
};
#define NCOL 26 // max number of columns (A..Z)
#define NROW 50 // max number of rows
struct grid {
struct cell cells[NCOL][NROW];
};
</code></pre>
I doubt that 171 KB of static allocation would fly on an Apple II! I do wonder how they did memory allocation, it must have been tricky with all the fragmentation.
According to Bob Frankston, Bricklin's co-founder[1]:<p>> The basic approach was to allocate memory into fixed chunks so that we wouldn't have a problem with the kind of breakage that occurs with irregular allocation. Deallocating a cell freed up 100% of its storage. Thus a given spreadsheet would take up the same amount of space no matter how it was created. I presumed that the spreadsheet would normally be compact and in the upper left (low number rows and cells) so used a vector of rows vectors. The chunks were also called cells so I had to be careful about terminology to avoid confusion. Internally the term "cell" always meant storage cell. These cells were allocated from one direction and the vectors from the other. When they collided the program reorganized the storage. It had to do this in place since there was no room left at that point -- after all that's why we had to do the reorganization.<p>> The actual representation was variable length with each element prefixed by a varying length type indicator. In order to avoid having most code parse the formula the last by was marked $ff (or 0xff in today's representation). It turned out that valid cell references at the edges of the sheet looked like this and created some interesting bugs.<p>It leaves out a lot of details - if you're skimping enough you could allocate variable length row vectors, but it seems they wanted to avoid variable length allocations, in which case you could start with a 255 byte array pointing to which subsequent equal-sized chunk represents each in-use row. You'd need at most 126 bytes per row in actual use to point into the chunks representing the cell contents. But this is just guesses.<p>[1] <a href="https://www.landley.net/history/mirror/apple2/implementingvisicalc.html" rel="nofollow">https://www.landley.net/history/mirror/apple2/implementingvi...</a>
and <a href="https://news.ycombinator.com/item?id=34303825">https://news.ycombinator.com/item?id=34303825</a>
Dan Bricklin wrote a JavaScript spreadsheet engine around 2008 <a href="https://github.com/DanBricklin/socialcalc" rel="nofollow">https://github.com/DanBricklin/socialcalc</a>. I extended it and adapted it to Drupal CMS around that time <a href="https://www.drupal.org/project/sheetnode" rel="nofollow">https://www.drupal.org/project/sheetnode</a>.
<i>> Maintaining a dependency graph would give us the most efficient updates, but it’s often an overkill for a spreadsheet.</i><p>It's not overkill at all. In fact, it's absolutely necessary for all but the simplest toy examples.
Are there good command-line interfaces for spreadsheets? I don't do anything super financially-important and I'd prefer to stay in the terminal for quick editing of things, especially if I can have Vi keybindings.
There is SC and now sc-im: <a href="https://github.com/andmarti1424/sc-im" rel="nofollow">https://github.com/andmarti1424/sc-im</a><p>You can also literally run Lotus 123 if you want. Someone has binaries to make it work on linux. or under dosemu
Neat, thank you! sc-im looks amazing, and it's even in the Fedora repos (though the repo version doesn't support xlsx, so I'll compile myself and try it out)<p>Edit: Quite painless! Opened some test xlsx files without issue. Did get a stack trace on a very complicated one, so when I have time I'll try and dig in deeper. Added a doc to the wiki in case it's helpful to other: <a href="https://github.com/andmarti1424/sc-im/wiki/Building-sc%E2%80%90im-with-xls-support-on-Fedora" rel="nofollow">https://github.com/andmarti1424/sc-im/wiki/Building-sc%E2%80...</a>
Visidata[0] is a killer data swiss army knife. It's even inspired off Visicalc<p>[0] <a href="https://www.visidata.org/" rel="nofollow">https://www.visidata.org/</a>
It's weird but visidata is my favorite spreadsheet.<p>"But... visidata is not a spreadsheet"<p>I know, that's what makes it so weird.<p>On contemplation, I think I grew dissatisfied with the normal spreadsheet data model, I wanted something bettered structured than the "it's a big bag of cells" that spreadsheets present, I wanted row security. The best I found was the relational database. I currently use a local postgres db for most things I would have used a spreadsheet for. The interfaces sort of suck in comparison but at least I have sane data structures.
I want to mention teapot. First an apology, it's not actually a good match for for question, sure, it's a curses spreadsheet, but it was made by someone who thought about the fundamentals of the problem a little too much. So it is probably a little too weird for someone who just wants to spreadsheet as Dan Bricklin intended.<p><a href="https://www.syntax-k.de/projekte/teapot/" rel="nofollow">https://www.syntax-k.de/projekte/teapot/</a><p>In short cell address are normalized @(1,2,3) instead of A1 or r1c1. real references so address rewriting hacks($A$1) are not needed. formula references so you can use a single master formula, and clocked expressions which allow circular dependencies/simulation.<p>Probably a little too different for casual use but worth taking a look at, if nothing else to challenge your ideas of what a spreadsheet has to be.<p>While looking up the website I found a rewrite in rust, which is cool I guess, someone is keeping the dream alive, I will leave a link to that as well.<p><a href="https://github.com/veridit/teapot" rel="nofollow">https://github.com/veridit/teapot</a>
I actually created one for some time ago. It's nothing special but it has Vi keybindings.<p><a href="https://github.com/RauliL/levite" rel="nofollow">https://github.com/RauliL/levite</a>
This might be programmer-brain, but I find sqlite is pretty nice for things people would use a spreadsheet for. It’s a little bit higher friction, but when I started designing a Improv-like terminal spreadsheet a while ago, I eventually realized I was just reinventing databases.
Emacs with org-mode and evil-mode seems to be up your alley.
Oh man, a TUI spreadsheet application that can edit ODF or XLSX format would be absolutely killer. Would love to hear if anyone knows of such a tool
It's a bit low on my priority list, but I'm working on that!<p><a href="https://github.com/ironcalc/TironCalc" rel="nofollow">https://github.com/ironcalc/TironCalc</a>
A slightly larger implementation at the end of the post does that to some extent - <a href="https://github.com/zserge/kalk" rel="nofollow">https://github.com/zserge/kalk</a> (CSV import export, Excel-like "locking" of rows/columns like $A$1). If there's a need for such a project - I'm happy to add ODF or XLSX, more compatibility with Excel formulas etc. I'm not sure about Vi keybindings, I personally find spreadsheets easier to use in a non-modal manner.
I would think visidata could.<p><a href="https://www.visidata.org/" rel="nofollow">https://www.visidata.org/</a>
Pretty sure I can build one based on code I already have. If others are interested in this, please let me know and I'll bang it out in the next couple of weeks.
<a href="https://github.com/zaphar/sheetsui" rel="nofollow">https://github.com/zaphar/sheetsui</a>
vibe one. ;-)
sc has been around for quite a while: <a href="https://github.com/robrohan/sc" rel="nofollow">https://github.com/robrohan/sc</a> there are several versions floating around.
This was one of the projects students did when I helped teach APCS to high schoolers as a TEALS volunteer (FracCalc).<p>Some of the implementations went way overboard and it was so much fun to watch and to play a part.<p>Even as a “seasoned” developer I learned some tidbits talking through the ways to do (and not do) certain parts. When to store input raw vs processed, etc.
VisiCalc has, undoubtedly, the highest impact-to-complexity ratio in the history of software so far.
Anyone know what kind of departments/parts of business were the first adopters of visicalc?
All kinds of operational departments. I'm sure it was used for accounting, payroll and commissions, inventory tracking, I know that teachers used it for gradebooks as I helped set them up when I was in high school (early 1980s).<p>Pretty much anything that you used to do on paper with a columnar notebook or worksheet and a calculator, or anything that could be represented in tabular form could probably be implemented in VisiCalc, Lotus 123, and others. Spreadsheets are probably the most successful software application that was ever invented. Certainly one of the most.
One of my most vivid memories from childhood was being in a computer store which sold Apple ][s when a gentleman drove up in an (awesome) black Trans Am and declared to the salesperson, "I want a Visicalc" --- after explaining that it was a computer application and that the potential customer didn't have an Apple, the salesperson proceeded to put together pretty much my dream machine (at the time), an Apple ][ w/ dual-disk drives and 80 col. card and green display and 132 col. dot matrix printer, and of course, a copy of Visicalc.<p>After paying by writing out a check, I helped load everything into his car and he drove off into the sunset --- I was then allowed to choose a reformatted disk from the box as a reward and chose _The Softporn Adventure_ (which I then stupidly removed the label from, but it wasn't something I wanted to explain to my parents...).
I would guess anybody doing bookkeeping or accounting.<p>Back then it was common for people to buy a whole system for their requirements. Hardware and software.
Accountants, and individuals within all kinds of businesses (what we today would call shadow IT). Imagine something like this:<p>* Person who deals with numbers all day goes to a computer store to browse.<p>* He sees VisiCalc, and immediately understands what it can do. It *blows his mind*.<p>* He wants to buy it right away. Pays for $2000 Apple II computer with disk drives to run $100 software; price is no object.<p>* Shows friends and colleagues.<p>* They rush to computer store. Repeat.
Reminds me of <a href="https://tomasp.net/blog/2018/write-your-own-excel/" rel="nofollow">https://tomasp.net/blog/2018/write-your-own-excel/</a>
This a great article - both interesting and potentially really useful to folks teaching- or learning- programming.
Other open source command line spreadsheets:<p><pre><code> https://github.com/drclcomputers/GoSheet
https://github.com/xi/spreadsheet/
https://github.com/andmarti1424/sc-im
https://github.com/saulpw/visidata
https://github.com/bgreenwell/xleak
https://github.com/SamuelSchlesinger/tshts
https://github.com/CodeOne45/vex-tui</code></pre>
Kinda cool to see... TBH, I'd be more inclined to reach for Rust and Ratatui myslf over C + ncurses. I know this would likely be a much larger executable though.<p>With MS Edit resurrected similarly, I wonder how hard it would be to get a flushed out text based spreadsheet closer in function to MS Excel or Lotus 123 versions for DOS, but cross platform. Maybe even able to load/save a few different formats from CSV/TSV to XLSX (without OLE/COM embeds).
Very nice read!<p>Though I think the definition of the parser struct should be<p><pre><code> struct parser {
const char* s;
const char* p;
struct grid* g;
};
</code></pre>
based on the rest of the code.
I’m genuinely worried that we’re the last generation who will study and appreciate this craft. Because now a kid learning to program will just say “Write me a terminal spreadsheet app in plain C.”
Which is somewhat akin to downloading one today. If, however, that same kid started small, with a data model, then added calculation, and UI and stepped through everything designing, reviewing, and testing as they went, they would learn a lot, and at a faster pace than if they wrote it character by character.
The thing is, any generation can say something similar. Just look at the article: it manages to produce and describe the creation of a simple spreadsheet, yet the code and accompanying description would only fill a small pamphlet.<p>There are various reasons for that, and those reasons extend beyond leaving out vital functionality. While C is archaic by our standards, and existed at the time VisiCalc was developed, it was programmed in assembly language. It pretty much had to be, simply to hold the program and a reasonable amount of data in memory. That, in turn, meant understanding the machine: what the processor was capable of, the particular computer's memory map, how to interface with the various peripherals. You sure weren't going to be reaching for a library like curses. While it, like C, existed by the time of VisiCalc's release, it was the domain of minicomputers.<p>I mean, can the current generation truly understand the craft when the hard work is being done my compilers and libraries?
[dead]