Hacker News Reader

Comment by smacktoward | Hacker News Reader

Yeah - my reaction to the idea of "spreadsheets for big data" is that it kind of misses the point of why spreadsheets are so popular, namely that most data is small data and a sheet of rows and columns is a super easy way to wrap your mind around a set of small data. So the big challenge is coming up with a way to work with small data that gives you the benefits a database brings over a spreadsheet (relations, querying, etc.) without losing that immediate "oh, I get this" feeling.

View on HN

The core problem of spreadsheets is that they should have been organized around tables with fixed data meanings from the beginning of the history of spreadsheets.

Instead the sheet is both layout tool and data "meaning" in one glob of garbage.

Apple tried to solve the issue with "Numbers" but ymmv on how well.

I disagree. The SUCCESS of spreadsheets is that they are general-purpose tools that deal with information laid out on a grid and they would be nowhere near as useful or powerful or indeed popular if it were otherwise (c.f. Numbers).

"Data laid out on a grid" is a paradigm that applies to a wide range of problems and spreadsheets are pretty much the only tool around that can deal with that entire paradigm. The user isn't stupid. The user has a use case that isn't being catered to.

If users had a clean and straightforward way to define the permanent header row, and viewed it as just what you did for a spreadsheet, the whole industry would be better off.

This is probably a glass half full/empty at the end of the day.

Fact is spreadsheets don't scale because they are sloppy and they don't provide a clean coherent path to getting the user to scale themselves into a sql like solution.

Oh well.

But doing that would limit spreadsheets to a tiny subset of what they're used for in the real world. If you have a permanent header row then you limit yourself to one table of data per page, which you often don't want.

Excel's tables are probably similar what you mean, but Microsoft rightly allow them as elements on each sheet rather than basing the sheet around one table.

"""Apple tried to solve the issue with "Numbers" but ymmv on how well."""

Your "tiny subset" is your confusion at not seeing numbers I suspect.

Wikipedia actually does a decent job of trying to describe the philosophy.

Numbers just doesn't do a good job of representing data grid information that isn't rows and columns of numerical/textual data. Its paradigm is that takes that subset of use cases and cleanly separates the presentation layer.

Excel has Tables, which sort serve a similar purpose, but the sheet itself is a flexible grid with no pre-conceived purpose, which makes it much more flexible than Numbers.

For example, it's relatively easy to knock up a simple Gantt chart by directly coloring cells, something that I've seen often. And you could argue that it's not the best tool for the job, and you'd be right, but it's easy and does the job well enough in many cases.

And that's why it's popular and iWork isn't. Numbers concentrated on making charts and tables beautiful; Excel is a general-purpose programmable platform.

Excel already has relations, albeit simple ones, as well as simplistic forms of querying, though filters and pivot tables.

I would argue that the major benefits that a database offers over Excel is data integrity and consistency. I think the lack of that sort of constraint is a major aspect of what drives 'biz' people to spreadsheets.

Reply on news.ycombinator.com