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

Tue Nov 21 02:52:07 UTC 2017

Middle posting follows.

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):
> > On Sun, Nov 19, 2017 at 3:40 AM Sergiu Ivanov <sivanov at colimite.fr>
> wrote:
> >> Thus quoth  trent shipley  on Sun Nov 19 2017 at 08:05 (+0100):
> >> >
> >> > I have a vision for a spreadsheet that is programmable as a
> spreadsheet
> >> > itself.
> >> [...]
> >> > * Is a spreadsheet you can program from the spreadsheet a reasonable
> >> > goal?
> >>
> >> What kind of use cases do you imagine for your programmable spreadsheet?
> >> "Reasonable" will usually depend on your context.
> >
> > I really haven't thought of specific use cases, but I have thought in
> > general terms about what you might do with a natively programmable
> > spreadsheet.
> >
> >    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.)

>
> >    2. It would be more elegant that the current solution to a
> programmable
> >    spreadsheet, which is a spreadsheet that is almost, but not quite
> >    programmable, with a helper imperative language and programming mode
> stuck
> >    onto the base spreadsheet.
>
> Well, as Olaf points out in another thread (I think), the fact that
> conventional spreadsheets are not completely programmable is also an
> advantage: you know what your spreadsheet _cannot_ do, which helps with
> debugging.
>
> I do admit that's not an argument against programmable spreadsheets,
> though.
>
> >    3. You could build a programmable spreadsheet on steroids with this
> >    idea, and I have some other interesting ideas, like "virtual
> spreadsheets"
> >    that would allow spreadsheets to extend into n dimensions (but I
> digress).
> >    4. So engineers, scientists, economists, and finance might have niche
> >    uses for a (n-dimensional) programmable spreadsheet on
> steroids--though I
> >    don't know in detail what those would be.
> >    5. I am a trained social scientist (anthropology) I know it is not
> >    uncommon for social scientists to have to deal with large,
> multidimensional
> >    datasets, and analyze the same. A multidimensional programmable
> spreadsheet
> >    might help a lot with that.
>
> 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.

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.

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

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

Might.

It might not for finance.

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.

>
> >    6. I have heard that finance wizards often use Excel+VBA to do
> modeling.
> >    They might like a consistent, single language programming environment
> that
> >    offers more power and type safety that Excel + VBA. It would also
> need to
> >    be FAST if it is to be used for something like market analysis or
> automated
> >    trading.
>
> 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.

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.

> > Finding plausible use cases is also hindered by both a version of an
> > existing spreadsheet enabling native functions, or a more full featured
> > Scriptsheets product both being vaporware.
>
> Not necessarily, as you showed in the message I am replying to :-)
>
> My reasoning behind suggesting to consider potential applications is
> that the abstract model you are mulling over is very general and can be
> implemented in various quite different ways—e.g., LibreOffice, Scilab,
> and the R language all focus on matrix processing (more or less), but
> they are so different that people seem to agree they are not really
> directly comparable, and thus not conflicting.
>
> 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.

> >> > It would be natural to use C++
> >>
> >> Using C++ looks in no way natural _to me_; "natural" will also depend on
> >> your use case ;-)
> >>
> >
> > The main argument for C++ is that if you are "reusing" existing code from
> > GNUmeric or LibreOffice Calc none of that is in a functional language. It
> > will tend to be in C++ (and maybe Java for Calc).
>
> Are you talking about the language for spreadsheet programming or about
> the implementation language for your project?
>

Implementation.

> If we are in the former case, the implementation language need not
> necessarily be the same as the language of the spreadsheet, like in the
> HotSpot JVM which seems to be written in C++ [0] even though it runs
> tons of other languages or Excel itself, which I doubt is written in
> VBA.
>
> As far as I know, Access, Excel, PowerPoint, and Word, are all implemented
in Microsoft C++.

> > 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.

>
> 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]).
>
> --
> Sergiu
>
> [0] https://en.wikipedia.org/wiki/HotSpot
>
> [1]
> http://paulspontifications.blogspot.fr/2013/01/when-haskell-is-faster-than-c.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171121/d2221b32/attachment.html>