> 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
