<div dir="ltr">Middle posting follows.<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 20, 2017 at 7:23 AM Sergiu Ivanov <<a href="mailto:sivanov@colimite.fr">sivanov@colimite.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Trent,<br>
<br>
Thus quoth trent shipley on Sun Nov 19 2017 at 12:12 (+0100):<br>
> On Sun, Nov 19, 2017 at 3:40 AM Sergiu Ivanov <<a href="mailto:sivanov@colimite.fr" target="_blank">sivanov@colimite.fr</a>> wrote:<br>
>> Thus quoth trent shipley on Sun Nov 19 2017 at 08:05 (+0100):<br>
>> ><br>
>> > I have a vision for a spreadsheet that is programmable as a spreadsheet<br>
>> > itself.<br>
>> [...]<br>
>> > * Is a spreadsheet you can program from the spreadsheet a reasonable<br>
>> > goal?<br>
>><br>
>> What kind of use cases do you imagine for your programmable spreadsheet?<br>
>> "Reasonable" will usually depend on your context.<br>
><br>
> I really haven't thought of specific use cases, but I have thought in<br>
> general terms about what you might do with a natively programmable<br>
> spreadsheet.<br>
><br>
> 1. It would be an interesting exercise in itself, and if it hadn't been<br>
> done before, might be worth a paper. (I submit that this is actually a real<br>
> use case.)<br>
<br>
That's a good and a fun use case, but it's probably not going to attract<br>
a lot of developers/maintainers.<br></blockquote><div><br></div><div>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. <span style="color:rgb(33,33,33);font-size:13px">"Spreadsheet Implementation Technology: Basics and Extensions", Peter</span></div><span style="color:rgb(33,33,33);font-size:13px">Sestoft, MIT Press. may provide fully functional spreadsheets for hacking (maybe based on </span><span style="color:rgb(33,33,33)">Forms/3 </span><font color="#212121"><a href="http://web.engr.oregonstate.edu/~burnett/Forms3/forms3.html">http://web.engr.oregonstate.edu/~burnett/Forms3/forms3.html</a>, at least in part. Forms/3 was M Burrnett's spreadsheet for HCI research.)</font><br style="color:rgb(33,33,33);font-size:13px"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 2. It would be more elegant that the current solution to a programmable<br>
> spreadsheet, which is a spreadsheet that is almost, but not quite<br>
> programmable, with a helper imperative language and programming mode stuck<br>
> onto the base spreadsheet.<br>
<br>
Well, as Olaf points out in another thread (I think), the fact that<br>
conventional spreadsheets are not completely programmable is also an<br>
advantage: you know what your spreadsheet _cannot_ do, which helps with<br>
debugging.<br>
<br>
I do admit that's not an argument against programmable spreadsheets,<br>
though.<br>
<br>
> 3. You could build a programmable spreadsheet on steroids with this<br>
> idea, and I have some other interesting ideas, like "virtual spreadsheets"<br>
> that would allow spreadsheets to extend into n dimensions (but I digress).<br>
> 4. So engineers, scientists, economists, and finance might have niche<br>
> uses for a (n-dimensional) programmable spreadsheet on steroids--though I<br>
> don't know in detail what those would be.<br>
> 5. I am a trained social scientist (anthropology) I know it is not<br>
> uncommon for social scientists to have to deal with large, multidimensional<br>
> datasets, and analyze the same. A multidimensional programmable spreadsheet<br>
> might help a lot with that.<br>
<br>
Multidimensionality seems to be a really important point in your<br>
project. On the other hand, without having any specialised knowledge in<br>
spreadsheet-crunching, I'm tempted to suppose that what these scientist<br>
need is quite below Turing completeness, once multidimensionality is<br>
provided.<br>
<br></blockquote><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Also, if sheets can be marked as being functions, virtual workbooks can support libraries of functions, or objects, if you want such things.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do you think a semi-programmable (as in LibreOffice) multidimensional<br>
spreadsheet may cut it for them?<br></blockquote><div><br></div><div>Might.</div><div><br></div><div>It might not for finance.</div><div><br></div><div><a href="https://arxiv.org/abs/0909.2452">https://arxiv.org/abs/0909.2452<br></a></div><div><a href="https://arxiv.org/abs/0909.2452"><br></a></div><div>See also:</div><div><a href="http://www.eusprig.org/index.htm">http://www.eusprig.org/index.htm</a><br></div><div><a href="http://www.eusprig.org/best-practice.htm">http://www.eusprig.org/best-practice.htm</a><br></div><div><br></div><div>I have to admit I haven't poked around as much as I should before passing these references on.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 6. I have heard that finance wizards often use Excel+VBA to do modeling.<br>
> They might like a consistent, single language programming environment that<br>
> offers more power and type safety that Excel + VBA. It would also need to<br>
> be FAST if it is to be used for something like market analysis or automated<br>
> trading.<br>
<br>
Your argument is probably based on way more experience than mine, but<br>
personally I don't at all aspire to have a homogeneous language<br>
environment. I actually like the separation in Excel: formulas for<br>
almost any operations; VBA when real muscle-power is inevitable.<br>
<br>
That was my two-cent addition to the brainstorming :-)<br></blockquote><div><br></div><div><div>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.</div></div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Finding plausible use cases is also hindered by both a version of an<br>
> existing spreadsheet enabling native functions, or a more full featured<br>
> Scriptsheets product both being vaporware.<br>
<br>
Not necessarily, as you showed in the message I am replying to :-)<br>
<br>
My reasoning behind suggesting to consider potential applications is<br>
that the abstract model you are mulling over is very general and can be<br>
implemented in various quite different ways—e.g., LibreOffice, Scilab,<br>
and the R language all focus on matrix processing (more or less), but<br>
they are so different that people seem to agree they are not really<br>
directly comparable, and thus not conflicting.<br>
<br>
Now, I may be mistaken and you may have a very clear idea of an<br>
implementation, in which case my suggestions are simply redundant.<br></blockquote><div><br></div><div>If implementation means "how to program it", I have no idea.</div><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>> > It would be natural to use C++<br>
>><br>
>> Using C++ looks in no way natural _to me_; "natural" will also depend on<br>
>> your use case ;-)<br>
>><br>
><br>
> The main argument for C++ is that if you are "reusing" existing code from<br>
> GNUmeric or LibreOffice Calc none of that is in a functional language. It<br>
> will tend to be in C++ (and maybe Java for Calc).<br>
<br>
Are you talking about the language for spreadsheet programming or about<br>
the implementation language for your project?<br></blockquote><div><br></div><div>Implementation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If we are in the former case, the implementation language need not<br>
necessarily be the same as the language of the spreadsheet, like in the<br>
HotSpot JVM which seems to be written in C++ [0] even though it runs<br>
tons of other languages or Excel itself, which I doubt is written in<br>
VBA.<br>
<br></blockquote><div>As far as I know, Access, Excel, PowerPoint, and Word, are all implemented in Microsoft C++.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Also, if speed is of the essence, my impression is that C++ and C come to<br>
> the fore.<br>
<br>
Yes, but overoptimisation along one criterion among many is also an<br>
issue. The trade-off between faster code or code easier to maintain is<br>
a difficult one.<br></blockquote><div><br></div><div>Financiers' market trading code is notorious for being time critical, they are trying to beat other trading companies to the market.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But then you're are right, C++ and C are often quite in the lead in what<br>
concerns speed (even though some tweaks may bring other programming<br>
languages quite close [1]).<br>
<br>
--<br>
Sergiu<br>
<br>
[0] <a href="https://en.wikipedia.org/wiki/HotSpot" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/HotSpot</a><br>
<br>
[1] <a href="http://paulspontifications.blogspot.fr/2013/01/when-haskell-is-faster-than-c.html" rel="noreferrer" target="_blank">http://paulspontifications.blogspot.fr/2013/01/when-haskell-is-faster-than-c.html</a><br>
</blockquote></div></div>