Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VisiCalc Reconstructed

zserge.com

Post reply on HN
Print view View original

31–40 of 85 posts

Re: VisiCalc Reconstructed

#31

Post by gregates »

OliverM wrote: post #19
airstrike wrote: post #13

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

Isn’t the existence & success of visicalc a direct counter to this?

> Since the formulas did depend on each other the order of (re)calculation made a difference. The first idea was to follow the dependency chains but this would have involved keeping pointers and that would take up memory. We realized that normal spreadsheets were simple and could be calculated in either row or column order and errors would usually become obvious right away. Later spreadsheets touted "natural order" as a major feature but for the Apple ][ I think we made the right tradeoff.

It would seem that the creators of VisiCalc regarded this is a choice that made sense in the context of the limitations of the Apple ][, but agree that a dependency graph would have been better.

https://www.landley.net/history/mirror/apple2/implementingvi...

Edit: It's also interesting that the tradeoff here is put in terms of correctness, not performance as in the posted article. And that makes sense: Consider a spreadsheet with =B2 in A1 and =B1 in B2. Now change the value of B1. If you recalc the sheet in row-column OR column-row order, B2 will update to match B1, but A1 will now be incorrect! You need to evaluate twice to fully resolve the dependency graph.

Re: VisiCalc Reconstructed

#32

Post by airstrike »

SoftTalker wrote: post #27
airstrike wrote: post #23

Earlier quoted context omitted.

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"

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.

Keeping a dependency tree is not complicated

Re: VisiCalc Reconstructed

#33

Post by pstuart »

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

Re: VisiCalc Reconstructed

#34

Post by zserge »

freedomben wrote: post #11
bonsai_spool wrote: post #2

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.

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

A slightly larger implementation at the end of the post does that to some extent - https://github.com/zserge/kalk (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.

Re: VisiCalc Reconstructed

#35

Post by SoftTalker »

gregates wrote: post #31
OliverM wrote: post #19

Earlier quoted context omitted.

Isn’t the existence & success of visicalc a direct counter to this?

> Since the formulas did depend on each other the order of (re)calculation made a difference. The first idea was to follow the dependency chains but this would have involved keeping pointers and that would take up memory. We realized that normal spreadsheets were simple and could be calculated in either row or column order and errors would usually become obvious right away. Later spreadsheets touted "natural order" a…

Even LaTeX just brute-forces dependencies such as building a table of contents, index, and footnote references by running it a few times until everything stabilizes.

Re: VisiCalc Reconstructed

#36

Post by gregates »

SoftTalker wrote: post #35
gregates wrote: post #31

Earlier quoted context omitted.

> Since the formulas did depend on each other the order of (re)calculation made a difference. The first idea was to follow the dependency chains but this would have involved keeping pointers and that would take up memory. We realized that normal spreadsheets were simple and could be calculated in either row or column order and errors would usually become obvious right away. Later spreadsheets touted "natural order" a…

Even LaTeX just brute-forces dependencies such as building a table of contents, index, and footnote references by running it a few times until everything stabilizes.

VisiCalc didn't do this, though. It just recalculated once, and if there were errors you had to notice them and manually trigger another recalc.

Re: VisiCalc Reconstructed

#37

Post by SoftTalker »

airstrike wrote: post #32
SoftTalker wrote: post #27

Earlier quoted context omitted.

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.

Keeping a dependency tree is not complicated

It's more complicated than not keeping one, at least.

Re: VisiCalc Reconstructed

#38

Post by wslh »

fouronnes3 wrote: post #26

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 rec…

The idea of backward updating is fascinating but is not generally feasible or computable. What kind of problems can you solve backwardly?

Re: VisiCalc Reconstructed

#39

Post by paddy_m »

freedomben wrote: post #11
bonsai_spool wrote: post #2

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.

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

I would think visidata could.

https://www.visidata.org/

Re: VisiCalc Reconstructed

#40

Post by fouronnes3 »

wslh wrote: post #38
fouronnes3 wrote: post #26

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 rec…

The idea of backward updating is fascinating but is not generally feasible or computable. What kind of problems can you solve backwardly?

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

Post reply on HN