VisiCalc's Spreadsheets Changed the World
thenewstack.io
thenewstack.io
I'm of the opinion that spreadsheets are programming and, in fact, represent their own paradigm of data-focused, document-centric programming with tons of implicit parallelism and, as you mentioned, implicit control flow similar to declarative languages.
It's sneaking pure functional programming in through the back door, in fact, and it's only a conceit that it somehow isn't programming.
Well over $5,000, and people paid it - for a spreadsheet.
For business, a word-processor, at the time, you could take it or leave it, because a good pool typist and a dictaphone was all an executive needed. But, being able to do "What-If" on various business assumptions, in real-time, was a game-changer (esp. w/ all the consolidation M&A happening w/ conglomerates at the time).
You couldn't even buy that with real money before...
You could also buy a literal "word processor"—a piece of hardware much cheaper than a general-purpose computer, akin to a fancy electronically-buffered typewriter.
The full power of a computer with pixel-framebuffer display, wasn't really needed for what we today think of as "basic word processing" tasks. The goal of early word-processing software was either just to save you the trivial expense of an electronic word-processor (sort of like a calculator app saves you the expense of buying an electronic calculator); or to be full-blown desktop publishing software.
And I still think there's room for innovation. Not something cloud-based, but something that lies in the middle between a classic spreadsheet, and other concepts like Jupyter or the Mac's "Calca" app.
What I don't like about spreadsheets is that you can't document them, like literate explanations about what the calculation is or why. You can do that in Jupyter documents, but bringing in reactive calculations to Jupyter is still a very hacky affair, akin to invoking "recompile entire document" after every adjustment.
If I could have something that was more like a spreadsheet, meaning reactive calculations as a first class concept, but still one step away from the grid UI with room for documentation and explanation, I'd be very happy. Literate Spreadsheets, basically.
You can create financial models and turn them into APIs. The model-building aspect is basically as you describe and supports markdown documentation.
I think just having proper names and descriptions for entities (variables, charts, etc.) will be a big improvement over unnamed cell references (E5, AA2) when trying to understand how a model works, and being able to document + audit changes to the model/data is the next piece on top.
A guide was linked the other day: https://observablehq.com/@observablehq/observables-not-javas...
However at that level of power you have a useful tools as a programmer, not something that can be used by mere mortals.
You know that both Excel and LibreOffice Calc have a notes feature right?
Apple's Numbers had possibilities in this regard in that you could have multiple spreadsheet tables within a larger document that might have surrounding explanation, although you're wrestling with text in a text box for that. And Numbers itself is pretty inadequate for even intermediate spreadsheet usage - for instance it doesn't have XIRR or XNPV.
Take Jupyter's flexibility, add in tables, multiple sheets-per-documents, and reactive calculation, and allow it to run offline or as desktop software, and you're getting close.
Obligatory Joel Splosky "You Suck At Excel" link [1]. Mandatory viewing in my opinion!
I have a few decades of experience writing software, but I still aspire to one day be as good with my tools as he is with his.
Maybe try answering a similar question using code and see how easy it is
You can work up the correct syntax in the top cell with mid, left, right, etc. And then just copy down once you have it right and copy the resulting values to your editor.
There's also "text to columns" for parsing separated or fixed width text.
Just type `blah | vd -f fixed`
2017 https://news.ycombinator.com/item?id=15587048
The rest is, as they say, history.
You can see some behavior differences compared to modern spreadsheets, notably: there's no operator precedence in VisiCalc. 1 + 2 * 3 = 9 (instead of 7), because this imitated the behavior of simple calculators. Bricklin realized VisiCalc was competing against people with paper and calculators, and anything that made it harder or slower than that would hurt adoption.
- Formula references (to be used as function references)
- Formatting formulas (directly in formula section, not via conditional formatting)
- Format-querying functions (as isBold, cellFontFamily, textcolor)
- better non-macro controls
- in-cell controls (instead of floating control objects)
- dynamic ranges (ie. you can paste any number of input values and all connected ranges will expand to the needed size)
- better external data handling
- serialization formats native support (json, xml) - no more error prone string pseudoparsing and manual concatenation without proper escaping
- HTTP(S) client for executing API calls from formulas
- (above requires selective manual re-evaluation instead full-auto/all-manual options we have)https://www.npr.org/sections/money/2015/02/25/389027988/epis...
I think that a lot of the efficiency gains and economic growth that computers introduced are from spreadsheets. Where would business be today without them?
Obviously, these aren't the only programs that people use but individual bells and whistles aside, all the products in this space looked more alike than different by the early- to mid-80s. Even the advent of Windows didn't really change the basic model all that much.
While efficiency is normally considered good, I think that this set the stage to reduce human activity to a couple of cells on a spreadsheet that can be easily deleted to bump up the numbers. It's the equivalent of killing people by high-altitude bombing -- they're not people anymore, and the only concern is "yield".
As an engineer... I've always struggled with understanding spreadsheets. To me, it always seemed that writing code was strictly better. For example, as somebody mentions further down the thread, spreadsheets don't a) connect to external datasources easily, b) are very limited in terms of their UI (cells only!), and c) are impossible to manage, version control, and distribute.
It's why I started working on a project called Retool (https://tryretool.com). It's basically Excel, but every cell is a React component. And we don't store any data ourselves — we connect to whatever datasource you want to connect to — whether a database (postgres, mysql, etc.), or a HTTP / REST API (stripe, salesforce, etc.). And it's hosted by us on the cloud (or by you, in your own AWS), so distribution is easy: we handle deployments, authentication, authorization, etc. for you.
The goal is to let developers build a certain class of software really fast (for us, custom internal applications). Most internal applications are incredibly boring (tables, textinputs, buttons, etc.), and all do similar things (CRUD, basically).
It looks like there are a lot of hardcore spreadsheet users + engineers here... if you guys have any feedback, that'd be really appreciated. We just got started, and are looking for literally any feedback :). Thanks!