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

Hello Trent, Thus quoth trent shipley on Tue Nov 21 2017 at 03:52 (+0100):

On Mon, Nov 20, 2017 at 7:23 AM Sergiu Ivanov wrote:

...

Hello Trent,

Thus quoth trent shipley on Sun Nov 19 2017 at 12:12 (+0100):

...

1. It would be an interesting exercise in itself, and if it hadn't been done before, might be worth a paper. (I submit that this is actually a real use case.)

That's a good and a fun use case, but it's probably not going to attract a lot of developers/maintainers.

No it wouldn't I suppose. It would be a way to get it started, and to explore new possibilities, but the academic use case certainly won't produce stability. Actually a few fully functional spreadsheets have been developed, mostly to explore the spreadsheet as a visual programming tool, or human computer interaction. "Spreadsheet Implementation Technology: Basics and Extensions", Peter Sestoft, MIT Press. may provide fully functional spreadsheets for hacking (maybe based on Forms/3 http://web.engr.oregonstate.edu/~burnett/Forms3/forms3.html, at least in part. Forms/3 was M Burrnett's spreadsheet for HCI research.)

That looks like an interesting reference, thank you, I'll try giving it a look.

...

Multidimensionality seems to be a really important point in your project. On the other hand, without having any specialised knowledge in spreadsheet-crunching, I'm tempted to suppose that what these scientist need is quite below Turing completeness, once multidimensionality is provided.

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.

OK, I see.

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.

OK, so you have an arbitrary tree, at the leaves of which there are 3-dimensional sheets. I've never heard of any spreadsheet application capable of doing that.

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

I see, you probably want some kind of first-class sheets in your language (modules/libraries of sheets, etc.)

...

Do you think a semi-programmable (as in LibreOffice) multidimensional spreadsheet may cut it for them?

Might.

It might not for finance.

OK, I see, noted.

https://arxiv.org/abs/0909.2452

https://arxiv.org/abs/0909.2452 See also: http://www.eusprig.org/index.htm http://www.eusprig.org/best-practice.htm

I have to admit I haven't poked around as much as I should before passing these references on.

All right, I must admit I didn't know there were so many people discussing spreadsheets, although that shouldn't come as a surprise given the widespread use of this tool. Thank you for the references.

...

Your argument is probably based on way more experience than mine, but personally I don't at all aspire to have a homogeneous language environment. I actually like the separation in Excel: formulas for almost any operations; VBA when real muscle-power is inevitable.

That was my two-cent addition to the brainstorming :-)

S Jones, M Burnett, and A Blackwell called this (disparagingly) "the trap door model". It has also been called the "bolt on" model. It's not that bad. It does require two sets of knowledge, and rather separate skill sets. I'm really not that hostile to it. It works, but I do like to have more than one way to do things. A fully functional spreadsheet would be a nice alternative.

I see.

Programmers have to learn multiple languages, and most wind up liking it.

That raises an important point: is your target audience programmers or finance wizards? Finance wizards will probably not like learning multiple languages, but you are probably aiming at being more general.

...

Now, I may be mistaken and you may have a very clear idea of an implementation, in which case my suggestions are simply redundant.

If implementation means "how to program it", I have no idea.

If implementation means refining a proposal, and leading into a functional spec, then, yes, I am working on that. Up to now mostly in my own head, which is why I'm seeking input, validation, and criticism. Depending, I'll go back and refine what I have.

Yeah, that's what I meant. Thanks for sharing your ideas :-)

...

...

Also, if speed is of the essence, my impression is that C++ and C come to the fore.

Yes, but overoptimisation along one criterion among many is also an issue. The trade-off between faster code or code easier to maintain is a difficult one.

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

I see. I'll probably tend to agree with what Joachim said in a later message, but I can't have an educated opinion given that I've never worked in time-critical systems. -- Sergiu