Might be worth looking at PySpread if you're into this kinda thing:
http://manns.github.io/pyspread/
On Sat, Jul 27, 2013 at 10:38 PM, Davison <otob...@gmail.com> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
