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

51–60 of 85 posts

Re: VisiCalc Reconstructed

#51

Post by somat »

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.

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.

https://www.syntax-k.de/projekte/teapot/

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.

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.

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.

https://github.com/veridit/teapot

Re: VisiCalc Reconstructed

#52

Post by OliverM »

airstrike wrote: post #50
OliverM wrote: post #48

Earlier quoted context omitted.

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.

Re: VisiCalc Reconstructed

#53

Post by fiddlerwoaroof »

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.

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.

Re: VisiCalc Reconstructed

#54

Post by mlhpdx »

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.

Re: VisiCalc Reconstructed

#55

Post by II2II »

khazhoux wrote: post #17

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

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?

Re: VisiCalc Reconstructed

#56

Post by AlotOfReading »

fouronnes3 wrote: post #40
wslh wrote: post #38

Earlier quoted context omitted.

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

Have you looked into prolog/datalog? You're dancing around many of the same ideas, including backwards execution, constraint programming, stratification, and finding possible values. Here's a relevant example of someone solving a problem like this in prolog:

https://mike.zwobble.org/2013/11/fun-with-prolog-write-an-al...

Re: VisiCalc Reconstructed

#59

Post by skaushik92 »

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?

Speaking from experience, I find budgeting spreadsheets to be a great usecase for this.
Post reply on HN