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

[Joachim Durchholz]

Am 21.11.2017 um 08:13 schrieb trent shipley:
>     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"?
> 
> They are not mutually exclusive. A workbook can contain sheets--just 
> like now. IN ADDITION, you can put workbooks in workbooks, until you 
> reach the root workbook, which is also a file.

Not an answer that helps me understand your point.

>      > 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.
> 
> 
> (No longer Haskell discussion, but anything civil goes in Cafe)
> 
> Sounds both interesting and relevant, but I don't quite get it. Can you 
> provide a simple, concrete, narrative example--with pictures (ASCII 
> OK)--if possible.

Nah, I'm only good at walls of text.
And at answering directed questions - start asking about what exactly 
you didn't understand.
Guessing what you might have not understood is going to be a waste of 
everybody's time.
(Besides, if you need to tell where exactly you didn't understand may 
help your understanding. Well, the keyword being "may"; I know it worked 
for me on various occasions.)

>     There's pivot tables, so the difference between row and column isn't as
>     clear-cut as the above assumes.
> 
> Don't worry about pivot tables. Simple cases first.

You have to design for the maximum complication.
Otherwise, stuff will not fit in well, and you'll be stuck with either a 
half-assed solution, nothing at all, or a full rewrite.
Trust me. I've been coding and designing software for decades.

>     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.
> 
> Any suggestions for a GUI library--that kind of implies C++ or Java. 
> Ideally your GUI would be cross platform.

I know only the Java GUI landscape well enough to say anything.
In that area, dialog boxes, menus and such will be easy enough with any 
lib, but you'll be mostly on your own for the grid. Also if you aim for 
unlimited size you'll get into a lot of hairy memory management issues - 
a 64kx64k grid has 1 million cells, multiply that with 1KB per cell and 
you end with a memory footprint of a gigabyte. Evaluating a formula for 
each cell is going to get you a slideshow-like performance.
So... managing which cells are actually needed and which aren't is going 
to be a major point of the software.

Did I mention that coding a spreadsheet is a huge project? ;-)

>      > 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.
> 
> Doubt it.
> 
> A given plugin's installation could be automated and check for dependencies.

Heh. Famous last words.
The Java folks got a 90% solution working - just for managing 
dependencies, mind you; for some people it doesn't work at all because 
they don't know how to get past the corporate firewall. Besides, most 
corporate firewalls do a man-in-the-middle certificate nowadays and will 
inspect and reject some packets and not others, so any update mechanism 
must be able to deal with wilfully unreliable internet connections.

So that's another area that's going to bind a lot of developer resources.