visicalc was rewriten in the 80's for computers newer than the apple ][, so are you asking specifically about the original implementation or later implementations? it makes a difference and mostly disobviates the question.

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.

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.

Keeping a dependency tree is not complicated

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

But not keeping one has a cost too. Which cost is higher? Generally, I argue, not tracking dependencies is the higher cost for any real spreadsheet in production use cases.

The clause "it's absolutely necessary for all but the simplest toy examples" is what I was disagreeing with. But I wouldn't be surprised to hear that visicalc adopted one as soon as it was technically feasible in later versions.

visicalc is not the benchmark you think it is. it's decades old. this day and age, dependency graphs for any real world use case will definitely need a dependency graph. it helps no one to suggest otherwise, and actually makes light of a specific engineering task that will for a fact be required of anyone looking to build a spreadsheet engine into a product

I'm not suggesting otherwise. I'm saying that your "toy example" comment is very dismissive of something that was an extraordinary accomplishment of its day. They invented spreadsheets without it. Dependency graphs are excellent and widely useful things we should all be happy to adapt and reach for, far beyond spreadsheets. We should be grateful that they're available to all of us to build into software products so readily. I've used them repeatedly and I'm sure I will many times in the future.

What I'm trying to communicate is this: this product _invented_ spreadsheets, but you dismiss the implementation with a sneer.

I didn't dismiss Visicalc at all. In fact, I even said it had fantastic success.

I dismissed the article's claim that maintaining a dependency graph is overkill for a spreadsheet. That's a false statement. It might have been true at the time, but it's not true today. The phrase as written in TFA is poor form and misleading to beginners.