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

[Sergiu Ivanov]

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.

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

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

>    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 :-)

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

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

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.

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

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 --------------
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/20171120/bb6bb576/attachment.sig>