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

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