8 ms·

VisiCalc Reconstructed

231 points by ingve 7mo ago

afandian 7mo ago
Quote: #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]; }; 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.
- vidarh 7mo ago
  According to Bob Frankston, Bricklin's co-founder[1]: > 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. > 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. 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. [1] https://www.landley.net/history/mirror/apple2/implementingvisicalc.html https://www.landley.net/history/mirror/apple2/implementingvi... and https://news.ycombinator.com/item?id=34303825 https://news.ycombinator.com/item?id=34303825
bonsai_spool 7mo ago
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.
- rauli_ 7mo ago
  I actually created one for some time ago. It's nothing special but it has Vi keybindings. https://github.com/RauliL/levite https://github.com/RauliL/levite
  - vslira 7mo ago
    This is brilliant! Thank you for creating it
- chungy 7mo ago
  Emacs with org-mode and evil-mode seems to be up your alley.
  - zie 7mo ago
    and Emacs SES, built-in spreadsheets outside of Org-mode: https://www.gnu.org/software/emacs/manual/html_mono/ses.html#Top https://www.gnu.org/software/emacs/manual/html_mono/ses.html...
- zie 7mo ago
  There is SC and now sc-im: https://github.com/andmarti1424/sc-im https://github.com/andmarti1424/sc-im You can also literally run Lotus 123 if you want. Someone has binaries to make it work on linux. or under dosemu
  - freedomben 7mo ago
    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) 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: https://github.com/andmarti1424/sc-im/wiki/Building-sc%E2%80%90im-with-xls-support-on-Fedora https://github.com/andmarti1424/sc-im/wiki/Building-sc%E2%80...
tracker1 7mo ago
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. 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).
airstrike 7mo ago
> Maintaining a dependency graph would give us the most efficient updates, but it’s often an overkill for a spreadsheet. It's not overkill at all. In fact, it's absolutely necessary for all but the simplest toy examples.
- OliverM 7mo ago
  Isn’t the existence & success of visicalc a direct counter to this?
  - airstrike 7mo ago
    Is anyone using visicalc today? I'm not sure how its past success, however fantastic, can be translated into "a dependency graph is often an overkill for a spreadsheet"
    - SoftTalker 7mo ago
      A still-very-common use case for spreadsheets is just to manage lists of things. For these, there are no formulas or dependencies at all. Another is simple totals of columns of numbers. There are many common spreadsheet use cases that don't involve complicated dependency trees.
      - zserge 7mo ago
        It's a common CPU vs RAM decision to make. Dependency graph consumes memory, while recalculating everything for a number of iterations could happen on stack one formula at a time in a loop. On 6502 it mattered. On modern CPUs, even with RAM crisis I'm sure for 99.9% of spreadsheets any options is good enough. Say, you have 10K rows and 100 columns - it's 1M calculations to make.
      - airstrike 7mo ago
        Keeping a dependency tree is not complicated
breadsniffer 7mo ago
Anyone know what kind of departments/parts of business were the first adopters of visicalc?
- SoftTalker 7mo ago
  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). 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.
- TMWNN 7mo ago
  Accountants, and individuals within all kinds of businesses (what we today would call shadow IT). Imagine something like this: * Person who deals with numbers all day goes to a computer store to browse. * He sees VisiCalc, and immediately understands what it can do. It *blows his mind*. * He wants to buy it right away. Pays for $2000 Apple II computer with disk drives to run $100 software; price is no object. * Shows friends and colleagues. * They rush to computer store. Repeat.
- tonyedgecombe 7mo ago
  I would guess anybody doing bookkeeping or accounting. Back then it was common for people to buy a whole system for their requirements. Hardware and software.
  - bombcar 7mo ago
    Software was often more expensive than the computer - and sometimes by far! Managers loved spreadsheets more than the accountants I feel, being able to fiddle numbers and see what changed was, well, a game changer.
- WillAdams 7mo ago
  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. 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...).
khazhoux 7mo ago
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.”
- jdswain 7mo ago
  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.
- II2II 7mo ago
  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. 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. I mean, can the current generation truly understand the craft when the hard work is being done my compilers and libraries?
ivanpribec 7mo ago
Reminds me of spreadsheet-fortran (https://github.com/lwsinclair/spreadsheet-fortran https://github.com/lwsinclair/spreadsheet-fortran), a project creating a VisiCalc lookalike in FORTRAN 66, which even runs on a PDP-11.
airstrike 7mo ago
Reminds me of https://tomasp.net/blog/2018/write-your-own-excel/ https://tomasp.net/blog/2018/write-your-own-excel/
fouronnes3 7mo ago
Very cool article! 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! 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. > 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. 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]. [0] https://victorpoughon.github.io/bidicalc/ https://victorpoughon.github.io/bidicalc/ [1] https://ohmjs.org/ https://ohmjs.org/ [2] https://www.microsoft.com/en-us/research/wp-content/uploads/2018/03/build-systems.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
- wslh 7mo ago
  The idea of backward updating is fascinating but is not generally feasible or computable. What kind of problems can you solve backwardly?
  - fouronnes3 7mo ago
    > not generally feasible or computable You'd be surprised. It really depends on how you define the problem and what your goal is. My goal with bidicalc what to find ONE solution. This makes the problem somewhat possible since when there are an infinity of solution, the goal is just to converge to one. For example solving 100 = X + Y with both X and Y unknown sounds impossible in general, but finding one solution is not so difficult. The idea is that any further constraint that would help choose between the many solutions should be expressed by the user in the spreadsheet itself, rather than hardcoded in the backwards solver. > What kind of problems can you solve backwardly? This is the weakness of the project honestly! I made it because I was obsessed with the idea and wanted it to exist, not because I was driven by any use case. You can load some premade examples in the app, but I haven't found any killer use case for it yet. I'm just glad it exists now. You can enter any arbitrary DAG of formulas, update any value, input or output, and everything will update upstream and downstream from your edit and remain valid. That's just extremely satisfying to me.
pstuart 7mo ago
Other open source command line spreadsheets: 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
- somat 7mo ago
  If we are doing a survey, you missed one of the most interesting ones teapot https://www.syntax-k.de/projekte/teapot/ https://www.syntax-k.de/projekte/teapot/
4leafclover 7mo ago
Very nice read! Though I think the definition of the parser struct should be struct parser { const char* s; const char* p; struct grid* g; }; based on the rest of the code.
rnxrx 7mo ago
This a great article - both interesting and potentially really useful to folks teaching- or learning- programming.
mlhpdx 7mo ago
This was one of the projects students did when I helped teach APCS to high schoolers as a TEALS volunteer (FracCalc). Some of the implementations went way overboard and it was so much fun to watch and to play a part. 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.
ksr 7mo ago
Dan Bricklin wrote a JavaScript spreadsheet engine around 2008 https://github.com/DanBricklin/socialcalc https://github.com/DanBricklin/socialcalc. I extended it and adapted it to Drupal CMS around that time https://www.drupal.org/project/sheetnode https://www.drupal.org/project/sheetnode.
diablevv 7mo ago
[flagged]
manoDev 7mo ago
VisiCalc has, undoubtedly, the highest impact-to-complexity ratio in the history of software so far.
dualblocksgame 7mo ago
[flagged]
staplung 7mo ago
Cool article but I think the write-up no longer matches the actual code. Snippets in the article use `*p->p` a lot. The *p is a parser struct defined above as struct parser { const char* s; int pos; struct grid* g; }; Notice there is no `p` member within. Assume the author meant `*p->pos`? And indeed if you look at the code in github the parser struct is defined as struct parser { const char *s, *p; struct grid* g; }; So there's the missing `p`, even though it's no longer an int. So I presume the member variable was once known as `pos` but got renamed at some point. Some of the snippets did not get updated to match.

231 points by ingve 7mo ago

Quote: #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]; }; 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.

vidarh 7mo ago
According to Bob Frankston, Bricklin's co-founder[1]: > 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. > 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. 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. [1] https://www.landley.net/history/mirror/apple2/implementingvisicalc.html https://www.landley.net/history/mirror/apple2/implementingvi... and https://news.ycombinator.com/item?id=34303825 https://news.ycombinator.com/item?id=34303825

bonsai_spool 7mo ago

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.

rauli_ 7mo ago
I actually created one for some time ago. It's nothing special but it has Vi keybindings. https://github.com/RauliL/levite https://github.com/RauliL/levite
- vslira 7mo ago
  This is brilliant! Thank you for creating it
chungy 7mo ago
Emacs with org-mode and evil-mode seems to be up your alley.
- zie 7mo ago
  and Emacs SES, built-in spreadsheets outside of Org-mode: https://www.gnu.org/software/emacs/manual/html_mono/ses.html#Top https://www.gnu.org/software/emacs/manual/html_mono/ses.html...
zie 7mo ago
There is SC and now sc-im: https://github.com/andmarti1424/sc-im https://github.com/andmarti1424/sc-im You can also literally run Lotus 123 if you want. Someone has binaries to make it work on linux. or under dosemu
- freedomben 7mo ago
  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) 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: https://github.com/andmarti1424/sc-im/wiki/Building-sc%E2%80%90im-with-xls-support-on-Fedora https://github.com/andmarti1424/sc-im/wiki/Building-sc%E2%80...

tracker1 7mo ago

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. 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).

airstrike 7mo ago

> Maintaining a dependency graph would give us the most efficient updates, but it’s often an overkill for a spreadsheet. It's not overkill at all. In fact, it's absolutely necessary for all but the simplest toy examples.

OliverM 7mo ago
Isn’t the existence & success of visicalc a direct counter to this?
- airstrike 7mo ago
  Is anyone using visicalc today? I'm not sure how its past success, however fantastic, can be translated into "a dependency graph is often an overkill for a spreadsheet"
  - SoftTalker 7mo ago
    A still-very-common use case for spreadsheets is just to manage lists of things. For these, there are no formulas or dependencies at all. Another is simple totals of columns of numbers. There are many common spreadsheet use cases that don't involve complicated dependency trees.
    - zserge 7mo ago
      It's a common CPU vs RAM decision to make. Dependency graph consumes memory, while recalculating everything for a number of iterations could happen on stack one formula at a time in a loop. On 6502 it mattered. On modern CPUs, even with RAM crisis I'm sure for 99.9% of spreadsheets any options is good enough. Say, you have 10K rows and 100 columns - it's 1M calculations to make.
    - airstrike 7mo ago
      Keeping a dependency tree is not complicated

breadsniffer 7mo ago

Anyone know what kind of departments/parts of business were the first adopters of visicalc?

SoftTalker 7mo ago
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). 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.
TMWNN 7mo ago
Accountants, and individuals within all kinds of businesses (what we today would call shadow IT). Imagine something like this: * Person who deals with numbers all day goes to a computer store to browse. * He sees VisiCalc, and immediately understands what it can do. It *blows his mind*. * He wants to buy it right away. Pays for $2000 Apple II computer with disk drives to run $100 software; price is no object. * Shows friends and colleagues. * They rush to computer store. Repeat.
tonyedgecombe 7mo ago
I would guess anybody doing bookkeeping or accounting. Back then it was common for people to buy a whole system for their requirements. Hardware and software.
- bombcar 7mo ago
  Software was often more expensive than the computer - and sometimes by far! Managers loved spreadsheets more than the accountants I feel, being able to fiddle numbers and see what changed was, well, a game changer.
WillAdams 7mo ago
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. 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...).

khazhoux 7mo ago

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.”

jdswain 7mo ago
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.
II2II 7mo ago
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. 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. I mean, can the current generation truly understand the craft when the hard work is being done my compilers and libraries?

ivanpribec 7mo ago

Reminds me of spreadsheet-fortran (https://github.com/lwsinclair/spreadsheet-fortran https://github.com/lwsinclair/spreadsheet-fortran), a project creating a VisiCalc lookalike in FORTRAN 66, which even runs on a PDP-11.

airstrike 7mo ago

Reminds me of https://tomasp.net/blog/2018/write-your-own-excel/ https://tomasp.net/blog/2018/write-your-own-excel/

fouronnes3 7mo ago

Very cool article! 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! 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. > 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. 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]. [0] https://victorpoughon.github.io/bidicalc/ https://victorpoughon.github.io/bidicalc/ [1] https://ohmjs.org/ https://ohmjs.org/ [2] https://www.microsoft.com/en-us/research/wp-content/uploads/2018/03/build-systems.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...

wslh 7mo ago
The idea of backward updating is fascinating but is not generally feasible or computable. What kind of problems can you solve backwardly?
- fouronnes3 7mo ago
  > not generally feasible or computable You'd be surprised. It really depends on how you define the problem and what your goal is. My goal with bidicalc what to find ONE solution. This makes the problem somewhat possible since when there are an infinity of solution, the goal is just to converge to one. For example solving 100 = X + Y with both X and Y unknown sounds impossible in general, but finding one solution is not so difficult. The idea is that any further constraint that would help choose between the many solutions should be expressed by the user in the spreadsheet itself, rather than hardcoded in the backwards solver. > What kind of problems can you solve backwardly? This is the weakness of the project honestly! I made it because I was obsessed with the idea and wanted it to exist, not because I was driven by any use case. You can load some premade examples in the app, but I haven't found any killer use case for it yet. I'm just glad it exists now. You can enter any arbitrary DAG of formulas, update any value, input or output, and everything will update upstream and downstream from your edit and remain valid. That's just extremely satisfying to me.

pstuart 7mo ago

Other open source command line spreadsheets: 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

somat 7mo ago
If we are doing a survey, you missed one of the most interesting ones teapot https://www.syntax-k.de/projekte/teapot/ https://www.syntax-k.de/projekte/teapot/

4leafclover 7mo ago

Very nice read! Though I think the definition of the parser struct should be struct parser { const char* s; const char* p; struct grid* g; }; based on the rest of the code.

rnxrx 7mo ago

This a great article - both interesting and potentially really useful to folks teaching- or learning- programming.

mlhpdx 7mo ago

This was one of the projects students did when I helped teach APCS to high schoolers as a TEALS volunteer (FracCalc). Some of the implementations went way overboard and it was so much fun to watch and to play a part. 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.

ksr 7mo ago

Dan Bricklin wrote a JavaScript spreadsheet engine around 2008 https://github.com/DanBricklin/socialcalc https://github.com/DanBricklin/socialcalc. I extended it and adapted it to Drupal CMS around that time https://www.drupal.org/project/sheetnode https://www.drupal.org/project/sheetnode.

diablevv 7mo ago

[flagged]

manoDev 7mo ago

VisiCalc has, undoubtedly, the highest impact-to-complexity ratio in the history of software so far.

dualblocksgame 7mo ago

[flagged]

staplung 7mo ago

Cool article but I think the write-up no longer matches the actual code. Snippets in the article use `*p->p` a lot. The *p is a parser struct defined above as struct parser { const char* s; int pos; struct grid* g; }; Notice there is no `p` member within. Assume the author meant `*p->pos`? And indeed if you look at the code in github the parser struct is defined as struct parser { const char *s, *p; struct grid* g; }; So there's the missing `p`, even though it's no longer an int. So I presume the member variable was once known as `pos` but got renamed at some point. Some of the snippets did not get updated to match.