Lambda the Ultimate

http://graphics.stanford.edu/projects/spreadsheets/

Products like Mathematica have been successful in their niche, but more general-purpose user-editable active documents seem to have faced big usability barriers. Part of the problem may be identified in the above paper - the "trapdoor approach", in which actual customization of a "document" must take place in traditional programmer-land, requires significant investment on the part of the user to learn and use. This turns creating active documents into a traditional programmer's task, effectively off-limits to the average user, who is restricted to things like the "dumb" embedding of external objects in e.g. a Word document.

If users could, spreadsheet-like, easily click on an object/component and, using a language of comparable simplicity to Excel's formulae, relate it to other objects on the same page or on other pages, it would represent a huge advance in end-user programming. One could imagine (some) users creating their own user interfaces to complex systems which provide components that enforce some basic level of sanity.

This is nothing new, conceptually - it's a variation of the same component vision that has been thrown around at least since the early days of OpenDoc and OLE, if not since Vannevar Bush's conceptualization of hypertext systems in 1945. Although systems like this are theoretically possible now, they still don't usually rise to the level of being particularly end-user-programmable, and certainly aren't common. Customizable user home pages at portal sites might be the most ubiquitous, if impoverished, example.

Peyton-Jones et al may be onto something important here in terms of the usability of such systems. Excel is easy to reason about because it's lazy functional. As soon as you insert imperative components that interact in arbitrary ways with the rest of a sheet, mutating cell values for example, the user's ability to reason about the behavior of the sheet, in all but the simplest cases, is severely compromised.

So, we need to start developing lazy functional components that interact with their host environment in a pure functional and highly transparent way. QED. ;)

In a sense. But the important thing about spreadsheets is the execution/programming model they provide (based on recalculation). This is what makes spreadsheets more than just a collection of cells.

I've long been interested in the spreadsheet as a way to do programming, especially when not writing an app per se. I don't know how to create new functions for StarOffice (but it does have a VB-macro like language), but I could always learn that. For Dynapad (http://dynapad.swiki.net), I plan on creating a spreadsheet app that is very easy and natural to extend using Smalltalk.

One thing I"ve been trying to figure out lately is how to extend the Newton Spreadsheet, QuickFigure for NewtonWorks, with user-defined formulas written in NewtonScript. I found the frame (in NewtonScript speak, a frame is a Lua-table... a hash-table-like structure that make up NS objects) that contains the functions, but haven't been able to add anything to it. This would be a great tool to have as a person who knows some NewtonScript. :)

I agree, but I'm suggesting that perhaps this model might be extended beyond a grid mainly consisting of numbers, to collections of components that are programmed, and whose state is exposed, in similar fashion.

Of course, I can only provide a detailed description of this in person, since it requires quite a lot of waving of hands....

this model might be extended beyond a grid mainly consisting of numbers, to collections of components that are programmed
Essentially that's what Xerox Analyst did all those years ago. I believe Analyst let you write image-transformation cell-formulas, in the same way that you write numeric cell-formulas. You could have a row of cells containing images that were progressively transformed.

(Somebody out there knows how it really worked - I don't)

Reading the Wikipedia entry on Lotus Improv I was struck by the similarity it holds to certain other systems. Basically the Improv revolution was to allow you to name cells and then perform calculations using those names rather than some arbitrary locations. Does anyone else know a programming system that lets you bind names to values and express calculations in terms of those bindings? ;-)

This is not to say there aren't cool things you could do with a spreadsheet model but I think the PL theoretic aspects are quite simple and its the visual representation that is a large part of the power.

(setf a (getpoint) setf b (getpoint) add-line (a b))

instead of (add-line ((getpoint) (getpoint))

so it's not exactly a shining example of good functional programming... [okay - i cant remember Autolisp or Lisp well enough, it's been >10 years since I used either, but you get the idea I hope!]

Anyway, if we could get something like scheme, or haskell, or [insert favourite language here] in use by piggy-backing on top of a widely distributed app, that'd be good. Wouldn't it?

I just remembered - OpenOffice has java embedded in it in some way, perhaps the functional lang community should consider sneaking a good language in alongside java?

Just thinking out loud really.

http://www.moria.de/~michael/teapot/

(3rd paragraph after the feature listing)

OpenOffice has java embedded in it in some way, perhaps the functional lang community should consider sneaking a good language in alongside java?
To follow the experience reported in user-defined functions in Excel wouldn't it be better to extend the OpenOffice formula language rather than the OpenOffice macro language?
Rather than "sneaking a good language in" their design is ruthlessly driven by principles of user-centered design.

It offers more than that: http://udk.openoffice.org/