Hi Loryn,
DataNitro didn't go as far as Revolver, but seem to be doing well by
incrementally offering Python as a scripting language within Excel to
replace VBA. (https://datanitro.com/)
Regards,
Davison
On Sat, Jul 27, 2013 at 11:49 PM, Loryn Jenkins <lor...@gmail.com> wrote:
> > With the era of Lotus-123 officially ending, I wondered whether
> > spreadsheets in general are still necessary.
>
> Other people responding to this post have asked why the OP referenced
> Lotus 1-2-3's era as ending. I suspect the comment is in response to
> IBM end-of-lifeing Lotus 1-2-3.
> http://www.zdnet.com/goodbye-lotus-1-2-3-7000015385/
>
> > Can any Factor users think of a computation more easily handled by a
> > spreadsheet than by a text editor and the Listener?
>
> My minor response is to point out that there are a range of functions
> available in spreadsheets that are not yet available in Factor. For
> example, until I implemented my own functions, there were no
> time-value of money functions within Factor. There are plenty of
> functions, e.g. Excel's MIRR, that are not available in Factor (yet).
>
> My major response focuses on the style of user interaction afforded by
> spreadsheets. Spreadsheets allow users to "stage" data (enter data
> piecemeal), reshape the data, apply a calculation, incrementally add
> another calculation, etc. In my mind, it is the incremental
> construction of calculation, combined with the use spatial reasoning
> instead of sequential reasoning, that is the major benefit of
> spreadsheets. Additionally, in a spreadsheet one's data is stable:
> intermediate calculations display their results on the screen without
> any fear of "losing" them.
>
> Contrast this with a listener, where one's data is being constantly
> "consumed". The intermediate calculations are impermanent (without
> taking intermediate actions such as duplicating references or
> serialisation to a file). Moreover, the inputs (data from a file),
> intermediate results and outputs are placed in separate locations
> (text editor vs display in a listener) unless the user again takes
> action to write the results back to a file --- but this results in
> additional processing and cognitive overhead that spreadsheets do not
> require.
>
> So, I see spreadsheets as being a "great" prototyping environment for
> reasoning about business data. My major problem with spreadsheets is
> the lack of capacity to abstract from the spatial layout of the cells.
> This results in any serious spreadsheet containing massive code
> duplication. Moreover, testing a spreadsheet is difficult (without
> leaping out of the spreadsheet paradigm and using an associated
> programming language, e.g. VBA).
>
> I note that a company called Resolver Systems (based in the UK)
> attempted to introduce a new paradigm for spreadsheets, whereby
> spreadsheet calculations were re-interpreted into Python code, and
> then that Python code was deployable outside the spreadsheet paradigm
> entirely (I think). My understanding is that Resolver has also been
> discontinued due to poor sales.
> http://www.python.org/about/success/resolver/
>
> Looking at the user interface and code samples shown at the above
> link, I think that Resolver Systems were identifying the right problem
> --- lack of abstraction within spreadsheets, inability to intermix
> procedural logic with functional calculation --- with the wrong
> solution.
>
> The main problem with spreadsheets calculations is their lack of
> abstraction. Data input specification and calculation code is
> intermixed.
>
> Take this as a typical example:
> =AJ7+AK7*$AJ$26
>
> The purpose of this code is to estimate the cost of hot water in a
> shower. There are lots of problems with code in this style:
> 1. The data inputs are cryptic, not semantically labelled. (This is
> state of affairs is encouraged by Excel's user interface.)
> 2. The code is inherently bound to the cells from which *these* values
> are obtained. This impedes, for example, arbitrary creation of test
> suites (without designing the application for such testing up-front,
> which detracts from the great benefit of spreadsheets mentioned above:
> piecemeal experimentation).
> 3. The code cannot be called from other locations. If this code is
> reused, it is reused through copy-n-paste.
>
> The problem with the Python-based implementation of Resolver is that,
> as far as I can tell, didn't really address any of these issues. (One
> would have had to *design* code to be reused; which, again, defeats
> the purpose of incrementality and experimentation.)
>
> Now, as a thought experiment, imagine what would happen if one
> implemented a spreadsheet program within Factor's development
> environment. One could conceive of spreadsheet code as being Factor
> quotations, with intercell references being treated as localised
> "datastacks".
>
> Here is the equivalent stack of cell references:
>
> AJ7
> AK7
> $AJ$26
>
> And the code that operates on said cell references:
>
> [ * + ]
>
> Now, the locality of the cell references is discrete from the
> computation. There are several benefits:
> 1. This particular computation is callable from elsewhere in the
> spreadsheet. Let's say this computation lives at cell AL7. Another
> cell could call it like this:
>
> [ arbitrary-code ... AL7 ... arbitrary-code ]
>
> Here, the reference to AL7 is the reference to the function denoted by
> AL7, not AL7's value or local stack references. The function is
> referenceable, and then executable within the localised stack state of
> the calling cell. (Just like normal programs.)
>
> 2. This computation could then be incrementally abstracted. For
> example, giving it a name now allows semantic labelling ...
>
> [ arbitrary-code ... blend-water-cost ... arbitrary code ]
>
> ... which you can do in Excel, but few people do, or few do
> consistently, because the abstraction possibilities are so limited
> people don't bother.
>
> 3. Which now means that incremental construction of unit testing is
> feasible.
>
> 4. The final step is to extract the method into a library of
> functions, ready for reuse within spreadsheets or within standard
> Factor programs.
>
>
> This approach uses Factor as a full-blown scripting language within a
> spreadsheet. For example:
>
> When the reference stack consists of:
>
> A:A
>
> System interprets it as equivalent to { A1 A2 A3 A3 ... An }, allowing
> arbitrary code like this:
>
> [ [ positive? ] filter sum sqrt ]
>
> This weekend, I've implemented a "toy spreadsheet" (~50 LOC), which
> explores this notion. The list of things it doesn't do is way longer
> than the things it does. But I reckon this is a promising way to blend
> the strengths of Factor's concatenative, functional, reflective
> programming environment with spatiality, incrementality and
> experimentalism availability within spreadsheets.
>
> That, and another couple of dozen functions being implemented, could
> make for an awesome Refactoring Spreadsheet.
>
> NOTE: The IronPython implementation of Resolver was said to be 40,000
> LOC on release. I believe the concept sketched above would be
> implementable with far fewer LOC than this.
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
