[Haskell-cafe] Speculation, OT: Program a Spreadsheet

[Joachim Durchholz]

> I should be more careful with the distinction between multidimensional 
> spreadsheets and n-dimensional spreadsheets. Multidimensional 
> spreadsheets like Lotus Improv and Lighthouse Design's Quantrix (based 
> on Improv and ran on Steve Job's NextStep) were spreadsheets with a 
> sophisticated way to model data that was called "multidimensional", that 
> is not what I am referring to.
> 
> Assume an additional level to the spreadsheet's organization between a 
> workbook and a sheet called a "virtual workbook". A root (file) workbook 
> can contain virtual workbooks or sheets. A virtual workbook can also 
> contain virtual work books or sheets. Sheets are 3-dimensional, and then 
> you're done, but virtual workbooks can be nested as deeply as desired, 
> so a spreadsheet with virtual workbooks could model n-dimensions.

Which one it is that you are interested in?
"Three-dimensional" as in "we have row, column, and layer", or as in "we 
have hierarchical workbooks"?

> Also, if sheets can be marked as being functions, virtual workbooks can 
> support libraries of functions, or objects, if you want such things.

Sometimes I think Excel etc. got it all wrong.
People routinely reserve areas inside the spreadsheet for different 
tasks: input, intermediate results, output. Increasing the size of each 
area becomes a pain.

I'd want to have a spreadsheet where it's easy to define multiple sheets 
on the same "table". Extending the input sheet with another row 
automatically extends the output sheet by a row (and if you have rollup 
then we get more than one row). Intermediate sheets could be replaced by 
a function definition.

It's a bit of an ergonomic challenge; functions are much more abstract, 
and users will want to see how the results of applying a function to an 
input area look like. So the mental model might be that we still have 
intermediate sheets, but with just a single function, and the 
intermediate sheets can be create, destroyed, shown and hidden easily.

The other challenge would be dealing with headers. Headers are 
important, but for the intermediate we have just the function so it 
needs to provide the headers. I.e. the function result would have to be 
a named tuple, and if you want multiline headers, we get a hierarchical 
named tuple.
Manipulating the column order would also manipulate the tuple 
definition, i.e. you'd have to think about how GUI manipulation affects 
the function definition.

There's pivot tables, so the difference between row and column isn't as 
clear-cut as the above assumes.

There are a few more things to consider. It's firmly in the GUI 
ergonomics area.
For this kind of stuff, you don't care whether the programming language 
evaluation semantics matches the problem domain (spreadsheet functional 
semantics is easy to do in any language, it was done in Assembler with 
Lotus 1-2-3), you care whether it is easy to prototype GUI approaches, 
which means GUI libraries that make it easy to create new widgets.

> Programmers have to learn multiple languages, and most wind up liking 
> it. They also have favorite languages. LibreOffice Calc has about four 
> bolt-on languages. As I recall, none of them are a functional 
> programming language. Maybe a few programmers should get together and 
> add one as a sub-project.

The problem is that any additional language needs to be installed. So 
either the new language needs to be integrated in the LO project, or it 
is not and anybody who passes on a spreadsheet in the new language needs 
to tell the recipients how to install the plugin for the language.

Maybe that's the reason why only the four languages exist.

> Financiers' market trading code is notorious for being time critical, 
> they are trying to beat other trading companies to the market.

Spreadsheets are irrelevant to high-speed trading, they'd be too slow 
anyway.
I am working for a company that operates a stock exchange, and rumor has 
it that the reaction times are down to 12 milli(!)seconds. Maybe it's 
not reaction time but ping time and the computation latency is on top of 
those 12 ms, but on a 4-GHz machine, 12 ms is 12,000 clock cycles, which 
is a pretty tight timescale to process dozens or maybe thousands of 
orders that have happened and post your own trade.

>     But then you're are right, C++ and C are often quite in the lead in what
>     concerns speed (even though some tweaks may bring other programming
>     languages quite close [1]).

I think one of the important factors is how much coder effort is needed 
to get that kind of performance.
The trade-off seems to be how much coder effort is needed to get the 
code correct.

 From what I hear:
C++ gives easy and predictable performance (if you code for that), while 
being somewhat unpredictable on correctness.
Haskell excels at correctness, gives reasonable but not very predictable 
performance.
Java is predictable with correctness though not excellent, and 
predictable with performance though not excellent.