Ask HN: What features do you want in a modern spreadsheet app?

This may be a very limited use-case, but....

I'm a one-man shop. Every month, using my (relatively quick and lightweight) spreadsheet software, I enter time worked for various clients, prepare timesheets and invoices for them... and then re-enter said data into my (slower, less friendly) accounting package.

The regular monthly stuff is almost always the same, very cookie cutter.

Having an accounting package is almost overkill, but it supports "accountant interoperability"[1] - and using the latter to do the former is definitely overkill. And I've never been able to figure out the automation/recurring capabilities, they seemed geared for more complex enterprises.

I hate the fact I enter data multiple times, I hate that I have to use the accounting package to manage expenses, etc., etc. - but integration and automation are complex, definitely overkill for my needs.

What I'd really like is the ability to use a spreadsheet for basic double entry bookkeeping (there are only a handful of accounts I use regularly; I can use the accounting package for the infrequent ones) and for entering my time, and have dirt-simple spreadsheet functions for generating client timesheets (sometimes based on the client's format, since my clients are often middlemen), for generating invoices (based on my format), and for generating a file that can be imported into my accounting package periodically.

+1 if the spreadsheet knows about regular monthly things and reminds/walks me through them.

Lightweight, fast, cross-platform. All the things my accounting package (Windows-only, so runs under a VM) is not.

[1] Accountants are like lawyers, IMHO: If you're unsure whether you need one, you probably do; my annual taxes cost me more than doing them myself, but I have greater assurance of minimizing my tax bill while staying off Revenue's radar - audits are expensive.

It's an interactive programming environment with an interface optimized for data entry and some other things. The difference between Excel and, say, Matlab or R, is excel's strength at data entry, visual/intuitive nature, and total lack of accessible higher-level programming features.

So the ideal solution in this problem space, to me, looks not much like excel at all, but more like a high-powered computation environment a-la mathematica, except with roughly the execution model and visual/accellerated/intuitive interface strength (and then some, as you suggest) of spreadsheets. For example, the whole grid thing might have to go, instead making tables first class objects in the language, and then have a strong visual representation with an accelerated (not plain text) interface for manipulating them.

But maybe you want to take it in a different direction than I do? In any case, excel can trace a pretty direct line to VisiCalc, with very little fundamental reevaluation applied since 1978 or so. So you might want to consider not being bound too closely to the "this is how spreadsheets have always been done" thing.

1: There's a reason that POI-HSSF, the Apache Java-to-Excel library, stands for Poor Obfuscation Implementation-Horrible SpreadSheet Format!

There's a terrible habit just about everywhere computers are used to use Excel as a catch-all table generator for whatever grid-like data someone wants to capture (task lists, for example). It's a terrible tool for that - the cell editor is actively hostile to entering text. And frankly, I think the majority of Excel use is for exactly this sort of clunky, awkward crud, not actual spreadsheeting.

Rather than trying to build a better spreadsheet, build a better grid-oriented text capturing device with some spreadsheet functionality.

The use case is to view which specifications are required per functional block in a large system.