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

[Sergiu Ivanov]

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 <sivanov at colimite.fr> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171122/8a5064ad/attachment.sig>