[Haskell-cafe] Speculation, OT: Program a Spreadsheet
jo at durchholz.org
Tue Nov 21 06:45:42 UTC 2017
> 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
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
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
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 ).
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
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
Java is predictable with correctness though not excellent, and
predictable with performance though not excellent.
More information about the Haskell-Cafe