Hacker News new | ask | show | jobs
by kqr 994 days ago
This section early on in the linked VisiCalc manual was actually helpful to me:

> The VisiCalc program was born out of the observation that many problems are commonly solved with a calculator, a pencil, and a sheet of paper — three nearly universal tools. Calculating sales projections, income taxes, financial ratios, your personal budget, engineering changes, cost estimates, and balancing your checkbook are done with these tools.

I've never thought of the spreadsheet as the computer equivalent of paper, pencil, and calculator.

That might sound odd, but coming from a programming background, I've always viewed it as some sort of limited-database-with-limited-scripting-abilities. I've even felt bad about using spreadsheets sloppily – not structuring data properly, applying formulae systematically, etc.

But "electronic paper, pencil, and calculator" does explain exactly how I often end up using spreadsheets, and now I know I shouldn't feel bad about it anymore!

4 comments

Spreadsheets are often abused as a bad version of a database, but they're pretty good when you just use them for their intended purpose to perform a series of numerical computations that show their work where you can play with it and see how it affects the results
A "spreadsheet" pre-dates computers. It literally was born from paper and pencil to record financial information and transactions in a ledger.

The innovation of the computer spreadsheet program is being able to put formulas in cells and auto-update and reference them elsewhere, all of which previously had to be done by hand (and with an eraser handy).

> program was born out of the observation that many problems are commonly solved with a calculator, a pencil, and a sheet of paper

Few apps for Linux and Android: TreeSheets[0], µMath+[1], Xournal++[2].

[0] https://strlen.com/treesheets/

[1] https://f-droid.org/en/packages/com.mkulesh.micromath.plus/

[2] https://xournalpp.github.io/

Most of what people in the real world are doing with spreadsheets would be better done with a database, but spreadsheets are more approachable so they use them instead. Making SQL a requirement for MBA programs would make business much better in the long run. (there are more things a MBA program could teach than there is time so I'm not advocating that they actually do this)
I’ve often wondered if just being able to change the “type” that applies to rows within a spreadsheet would be useful.

A general use string type being the current default, there’d be lots of benefited use cases to locking down rows (heading rows aside) as having to be safe format, or a number etc.

In Excel have you tried selecting a row and select the Text or the Number type from the ribbon "Types" drop-down (oddly named the "Number" section of the Home ribbon tab because it was classically the "Number" tab of the Format Cells dialog, which still exists if you click the expando button on the ribbon section)? (I find it easier to select columns and set types by columns, but I don't know what your spreadsheets look like.) It doesn't "lock" the type and an editor can still change the type for an individual cell, but you can still set (and save) better default expectations.

(Text is the safe string format that isn't as "magic" as General, the default. It's also the type you get if you use the " prefix in General.)

It's interesting to note here that the weird "magic" of Excel's default General "type" is pretty directly VisiCalc's fault because they had similar types but wanted to keep entry "simple" and decided to just guess types as people wrote cells with a handful of special character prefixes to override types. That legacy will likely forever live on. Excel could name General "VisiCalc Backward Compatibility" and it wouldn't entirely be wrong.

What Excel calls the Data Validation feature?
Sort of, but that is super brittle, doesn't quite have an understanding of "types" and is not really feature complete
My experience has been that teaching MBAs SQL just leads to MBAs desiring to execute Access-designed SQL statements (with horrifying execution plans) on Production database servers and expect to see the results in Access. That way lies its own madness.
They are different tools. Spreadsheets allow for much faster iteration than SQL.

Following some strict "best practices" when using spreadsheets gets you 80% of the way there. The other 20% is functionality that doesn't exist yet, but can be done.

For sure, but business runs on spreadsheets and most of them are places where SQL is clearly a better fit. Complex iteration is faster in SQL as well, though for simple problem sets spreadsheets are faster.