Mike Lambert asks for a clarification to my Future of Programming post, where I say: “I am exploring the “dual†of OO, in which the encapsulation of behavior is replaced by the publication of reactive structureâ€.
Alan Kay, who invented the term “Object-Oriented”, explains it as a model of computation where the fundamental building blocks, called objects, are each like little computers that cooperate by sending messages to each other. Implicit in this metaphor is that the little computers are communicating over a serial channel, by sending series of symbols.
I envision an alternative model of computation, where the fundamental building blocks are called structures. Each of these structures is still a little metaphorical computer, but with a richer interace than a serial channel: structures can be traversed, and edited. The system operates by reaction: one structure observes another, and modifies it. Modification to one part of a structure may cause a change to another part in response. Any structures observing this change may in turn react by changing themselves or other structures.
The metaphor of little computers can be extended to contrast these styles of computation. The little computers of object-oriented programming communicate over a serial channel that is like a traditional command-line interface. The little computers of structure-oriented programming interact as if using a direct-manipulation GUI. The irony of this metaphor is that object-orientation first flourished in the invention of GUI’s.
The trick is translating this cute analogy into a simple and powerful model of computation – one that uses structures “all the way down”. My first step towards this goal is subtext. There are many possible benefits to structure-oriented programming. The common “observer” pattern is built-in, as is the semantics of many “component” models (which require quite elaborate OO API’s). Abstraction can be achieved by constructing updateable views of other structures, much like in query languages, which offers a more declarative form of composition. There is one potential benefit that I particularly want to emphasize: making the execution of programs more immediate and visible to the programmer. The metaphorical GUI presented by every structure can be connected to an actual GUI, letting the programmer observe and modify the structure exactly as the other structures do. This is a completely transparent model of computation. In contrast, objects are black boxes that require sophisticated inspectors/debuggers/IDE’s to be usable, which in turn rely on priviledged meta-access that escapes the normal rules of the computational model.
I do not want to claim that structures are better than objects, only that they have been neglected in the enthusiasm for objects. I see them as complementary ways of understanding and building complex systems. I am exploring a purely structure-oriented style as an experiment to better understand the full spectrum of possibilities. In the end we need to harmoniously integrate structure-oriented and object-oriented styles.
It would be really awesome if you turn on full-text in your RSS feed . It would make life a lot easier for people like me who want to read your blog through an aggregator.
[Done — Jonathan]
Nice. I like your idea. I’m wondering what the basic mechanisms for observing and modifying structures would be? To me, just coming up with an elegant way to do those would be remarkable.
Mr. Edwards, have you had any experience with Margaret Burnett’s Forms/3 project? It appears to offer similar suggestions about direct manipulation in a declaritive context. Do you also see yourself in the “Visual Programming” space with subtext?
[Pete – funny you should mention that, as I was just writing up my Related Work section for a paper and discussing Forms/3 at length. The bottom line is that I share a number of goals and ideas with Forms/3. The difference is that Forms/3 tries to stay within the bounds of the existing spreadsheet metaphor. It very cleverly adds general purpose programming features to it, but these end up being quite intricate and complex. I am trying to come up with a new metaphor designed expressly for programming, and to make it very clean and simple.
As to visual programming, my point is that both textual and visual programming make the same mistake: thay conflate the model with the view. Text and graphics are best seen as user-interface techniques. Neither is particularly well suited to representing an abstract model of program semantics. — Jonathan]
Which reminds me, this paper (which should probably be required reading for all CS students!) is well worth a read, if you haven’t already:
Rapaport, William. “Implementation Is Semantic Interpretation.”
(I think it was published in a 1999 special issue of The Monist devoted to the philosophy of computer science, but I can’t seem to find a copy of it online. I’d be grateful for a URL if you find one!)
Here’r the link to “implementation is Semantic interpretation” http://www.cse.buffalo.edu/~rapaport/Papers/implementation.pdf