Spreadsheets: Functional Programming for the Masses (2014) [slides]

I think this is a good summary. Only MS and Goog truly know, but I've seen decent published estimates that Excel + Google Sheets have 1B+ users (https://medium.com/grid-spreadsheets-run-the-world).

So "low code" has been with us since the 1980's.

I am really curious about both sides of your comment, but I don't know where to start asking. How do you write parametrized SQL in a spreadsheet? And what is wrong with our data models? What even _are_ our data models?

I wish there were a better bridge from spreadsheets to full-blown applications, though. I imagine some kind of tool where you have your prototype spreadsheet and click "Export to application", and a wizard walks you through naming your columns, which then get exported as named arrays/matrices in a declarative/functional dataflow language. You name your formulas, which become named functions. You mark some of the cells as inputs and others as outputs, which then kicks you over to a GUI wizard for laying out the end-user UI. Cells that aren't formulas, inputs, or outputs become named constants in your program. Maybe there's JSON REST, Protobuf gRPC, and Bloomberg market data API integration for inputs and outputs.

I've spent the past 10 years maintaining and improving a finance-centric lazily-evaluated dataflow language with integrated distributed NoSQL database for a Fortune 500 financial services company. My understanding is that most of our competitors use Excel where we use our language/database. Some of our competitors have hired away some of our developers to explicitly write more modern clones of our system. One competitor's clone uses Python with function decorators that inspect the function's AST and transform it into a reactive dataflow language, though I imagine it's very frustrating to write something that looks like Python with very non-Pythonic evaluation semantics. I think starting with something like Haskell or Prolog would be less jarring.

My wife does finance/accounting for another large multinational, and I see the appeal and power of both Excel and our system. I wish there were some easier way to migrate from spreadsheets to more scalable and maintainable systems. (And, I suppose, there's some utility in bidirectional migration.)

Guy at support uses Excel to generate SQL statements.

Typically when we have a request like "oops, we accidentally entered wrong weights for these articles, please fix", where he gets an Excel sheet of article numbers and correct weights. But thanks to the flexible nature, toss in a little logic when needed for example, he can quickly churn out some non-trivial SQL to do the job.

Of course may other ways to do this kinda job, but for him this is quite productive. He starts by writing the query he needs for doing one update, then just stuff it into Excel, replacing fixed values with cell references and copy formula down all rows and copies result back into interactive SQL editor.

There's a real mixture:

I essentially had a spreadsheet driven CRM tool that could

Ping an internal data warehouse API Run data validation Generate email templates Send emails via outlook integration

So some of that wasn't FP as it used VBA but all the validation and checks were done using vanilla functions and were therefore functional.

But you're right, until I figured out how abstract and actually program, VBA script was bound to report generation before I started hitting unmaintainable complexity

Different approaches for different aspects. For discipline calculation sheets, there is not much other than having a basic file-level version control and validation engines for importing the data. For other areas, I have built pipelines that maintain diff-able JSON in a repo and handle converting to-from a spreadsheet for their 'UI'. We are also always using or building integrated solutions for data and calculation capturing. My personal push is to introduce discipline engineers to things like Jupyter notebook for "hand" calculations.

Explicitly tagging cells as I/O would remove all ambiguity that otherwise has to exist in any given spreadsheet. Knowing what could/couldn't me moved by tools opens a lot of possibilities. In fact, you could remove all non-IO cells to a list of formulae, to be editable in an IDE.

I hope that makes sense.