[Haskell-cafe] Speculation, OT: Program a Spreadsheet
sivanov at colimite.fr
Wed Nov 22 10:46:16 UTC 2017
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
>> > 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
>> 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
> 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?
> It might not for finance.
OK, I see, noted.
> See also:
> 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.
> Programmers have to learn multiple languages, and most wind up liking
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the Haskell-Cafe