component programming

Marshall McLuhan said that the interesting thing about a medium is what it makes the user become in order to use it.

What does Croquet make people become? Rick McGear, a Croquet advocate at HP, says that using Croquet makes us become programmers.

What is programming? The classic definition is of computational processes, but object-oriented programming seems to take a different view. And Croquet’s TeaTime architecture describes objects in terms of a mapping between message histories. I’m not finding process to be satisfying.

In school, Hal Abelson taught me that programming involved a means of combining simple primitives into compound expressions, and a means of abstraction by which compound objects can be named and manipulated as units.

Let’s look at abstraction first. I want to move to a direct manipulation UI. The user should never feel like they are dealing with a stand-in, but the thing itself. And I don’t want to be forced to manipulate them only by by name.

I do like the bit about combining things. But what are expressions? Do they define data? Well, Object Oriented programming tends to contain the data within objects, or have the data simply be objects with behavior. Do expressions define behaviors? I want to make it easy for people to chose behaviors, and maybe even define their own, but I don’t want to force anyone to do so just to be able to use the thing. No VCR programming required here, folks!

I think Rick means the act of choosing among things that were not present in the thing they start with. Composition. Expression of their ideas. Dropping in components is a crude example. Buying applications for a computer is an even more frequent minimal example. Buying or downloading new programs for a computer and then using them is a very simple act of programming. This is the difference between a computer versus a toy or appliance with exactly the same chips in it. The ordinary use of Croquet, by ordinary users, should be an act of composing the things they want for (interactive) presentation to others.

There’s a wonderful blog by a primary school teacher using Squeak (which Croquet is built upon).

Squeak lowers the barrier before they reach that first success, compared with more popular production programming languages. Components should lower that barrier even more. An incremental change, perhaps, but maybe significant nonetheless. Maybe even to a level where some level of programming is accessible to emerging readers.

“They define how the object works and they realize that if they can describe it in words, then they can probably make it happen on the screen. That is HUGE.”

With components, I expect it to be more like a treasure hunt. If they can imagine the solution – even if they don’t have the words to express it, they can go look for something that has the behavior they want. Then they can put that behavior in what they are building. If necessary, they might tinker some more until they get it to work in their component and in conjunction with the other behaviors they’ve collected. Only if they truly cannot find the behavior they want, do they have to start expressing themselves in specialized vocabulary, so that they can either spec out a new behavior or build it themselves.

The teacher goes on: “Squeak lets them dream way bigger than I am capable of leading.” The teacher talks of how the students ask her questions (even by IM when she’s away) that she cannot answer. Of course, Croquet is about collaboration. The students can use the medium itself for asking questions of each other, the teacher, the teacher’s colleagues, and the world at large. In asking those questions, they can easily present the very components they are working on. They can say, “I’d like it to do this forever after I click on it,” as they drag the component around in a figure-eight. The person they interact with can then act as a true mentor by showing them directly how to achieve the result. They can actually open up the relevant part of the component and point to it and say, “Here is where you need to add the thing.” Then they can go off together to look for the thing to be added. Another student sees them and asks, “What are you doing? Where are you going?” The other student is interested, goes along, and learns something unexpected.

In this way, I think that the compositional aspects of programming (assembling and presentation) begins to be an entry point for the “real” programming in which these basic behaviors are created. So the user starts “in the middle,” composing, selecting, editing, configuring, and directly manipulating pretty concrete objects and their concretely objectified behaviors. They get to skip all the weird abstract process oriented stuff and machine-oriented stuff. (Although I have a feeling that reifying timelines will let them directly manipulate processes as well, but I’m not there yet…)