[CamTin]

For non-technical people whose tasks have reached the limit of what can easily be maintained in Excel, it seems like you need the opposite as well--call it a spreadsheet decompiler, which outputs this hypothetical declarative DSL.

Alice in accounting maintains a set of spreadsheets for a number of years, and finally the task of adding some new feature, or porting it to a batch system in some production line-of-business system falls to Bob, a developer. Bob runs Alice's spreadsheet through the decompiler, spends some time refactoring it by adding descriptive names to some of the "variables," building tests, and generally structuring it for extensability and maintenance. Now he can compile it back to Excel and send it back to Alice and others that need it, or (and this is the really cool part), deploy as just another module in the ordinary business automation.

You've basically built a way to turn a spreadsheet hacked together by a domain expert and a small number of development man-hours into something much move valuable and maintainable.

I don't know much about enterprise-y reporting software, but it seems that if you built this, with the right integrations, you could probably sell quite a few copies of it, plus some high-buck support contracts.

[thanatropism]

This is a bit harder. An Excel spreadsheet has no self-evident order of evaluation -- the cell dependency graph can be arbitrarily complicated.

Of course, Excel itself (and other spreadsheet programs) already do "decompiling", but this works like an always-on loop that resolves the direct, algebraic dependencies but makes no distinction for business logic. This is probably true of most real decompilation tasks.