Last updated at 12:40 pm UTC on 16 January 2006
This is a draft in progress and a fairly personal perspective. I'll try to add more about contributions made by other people.
- Dan Ingalls
The Fabrik work began with a little spreadsheet I built in Smalltalk in 1980. The rules could be any Smalltalk expression, and you could choose different appropriate views to be used on any given cell. For instance if the rule for a cell computed a Form as a result, you could choose a FormView, and actually see the image dispayed in that cell.
This led to a free-form design (as opposed to the tabular spreadsheet layout) called Ariel. The rules and layout information were collected together as a class that could be filed out an into another Smalltalk. I added the original PluggableViews to ST-80 as part of this work. Some folks in El Segundo picked up the Ariel prototype, and it eventually grew into the Analyst system.
Graphical Composition of Expressions
I didn't pick up that work again until 1984. I had stopped at the point where I had a couple of graphically interesting examples, such as a calendar display. The reason I stopped was that the calendar example essentially consisted of a single spreadsheet cell with a monstrous big rule that computed the image of a calendar month, given the year, the month, and the frame size. The system provided flexible cell layout, and managed propagation of values to dependent cells, but the real problem for the user was to edit and debug this monster method. I was staring at that method one day and started to see it broken down into parts tha could be wired together in the visual space, and that became was the germ of Fabrik – to build up complex computations in the same graphical space in which their results were being displayed.
I tinkered with this concept for a while, but was mostly much occupied with getting Apple Smalltalk out the door (1984-5). The calendar example looked nice, but I kept having trouble dealing with collections. All the nice declarative properties of a wiring diagram seemed to fall apart when you tried to build a loop, because you had one clock on the outer variables, and another on the variables inside the loop.
Then I came across Dan Kimura's "Show and Tell Language". This was a system designed for easy access to databases, but it had a rigorous declarative (timeless) model for its relationship diagrams, and yet it dealt with collections. it is to this work that Fabrik owes its iterators, and the various iteration gateways. It was a perfect match, because the interation frames correspond nicely to Smalltalk blocks.
With the Apple Smalltalk work at a reasonable state of completion, I set to work full time on Fabrik, and was soon joined by Ken Doyle, YuYing Chow, Scott Wallace and later Frank Ludolph.
The pitch we made was that most applications required several separate endeavors – the design of a user interface, the code to support the various views and their sensitivity to user actions, and the actual semantics of the application which is usually pretty simple. The Fabrik approach was to slice this all vertically and define a set of components that captured a user interface idiom, the code to support it, the state of its values, and an interface for connecting these together in a consistent computing framework. This, of course is what we know today as a widget construction set. It did not take long before we could demonstrate a FileList browser built from scratch in 5 minutes.
I don't know exactly when we made bidirectionality work, but it was driven by my desire to build a Fahrenheit to Celsius converter as easily as in ThingLab. The breakthrough into timeless declarative diagrams meant that this no longer implied an inconsistency in the diagrams, but it did require separate analysis of what the connections meant in various input configurations (ie which connections were acting as sources and which as sinks). This led to the interpretation of a multidirectional wiring diagram as a shorthand for a number of superposed unidirectional diagrams, each of which obeyed the formal properties of dataflow.
From the very first roots of Fabrik, the ability to compute dependent images from changing values was a kernel concept. Therefore as soon as Fabrik became a real project, I tried to define an algebra of "graphemes" that would span most of the synthetic graphics of the 80's, and that could be composed by a relatively small set of graphical components. This was fun, and relatively straightforward – shapes, lines and text, together with translations, rotatations, scaling, superposition and clipping (which is just superposition with BitBlt rules). A breakthrough here was the realization that the grapheme objects that were computed in a forward direction could also propagate user input backward through the structure, and that a special component could tap off that use input at any point. We made a lot of noise when the bidirectional slider (figure 3 in the paper) first worked.
Until late in Fabrik's development all Fabrik evaluation was performed interpretively, with dependence order computed at edit time by a topological sort. One of the pitches we made while at Apple was that any Fabrik application could be simply translated to run in any other language on any other machine (this did not excite anyone ;-), given only an equivalent component library in the other host language on the other host machine. The project was cancelled before this ever happened, but we did carry through the compilation paradigm with Smalltalk as the target language (this was essentially all done by Scott Wallace). While this was never needed for portability, it would have allowed the Fabrik programming process to be applied to tasks where performance considerations were important.
In 1987 I left the field of computer research to take over a family business in the mountains of Virginia. Without a strong advocate in the political climate at the time, the remaining Fabrik team was quickly disassembled, and the work discontinued.
Just as I was about to leave Apple I became fascinate with the notion of combining Fabrik with the emergent Hypercard system. It seemed to provide a more intuitive scripting model for Hypercard, and also an ability to extend the widget set abitrarily, while at the same time giving Fabrik a model for storage, seraching and database access. It never happened.
Back to Fabrik
Back to Squeak Central project list