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).
“They love it when that first object moves forward, makes a noise and they are in CONTROL.”
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…)
"components" is a very elastic concept. I’m thinking about it.
I’m espescially thinking about it in the c context of Laszlo (where I’m the doc guy). We’re trying to devise a platform in which people can build applications by assembling "components", but what exactly does that mean?
http://www.laszlosystems.co…
I liked the teacher’s blog. Very thought-provoking.
Hey, I like that "Lazlo in 10 minutes" thing! Very nice. (But 10 minutes? Really?) Remember all the trouble we had getting "Curl in 10 minutes" published? Man, we were screwed up!
For component assembly in Laszlo, you really have to figure out what you’re trying to achieve. My components deliberately abandon the distinction between user and app developer. The idea is that anyone can do it for their own use, like anyone can draw their own signs on paper or build their own box out of 2x4s. But being digital and collaborative and P2P, people can share and reuse and recombine. It’s meant to facilitate a new (and much larger) culture.
Laszlo keeps a clear distinction between users and the initiated cult of developers. The very second paragraph of "10 minutes" emphasizes integration with existing (developer’s) IDE, source control, etc. Nothing wrong with that! You could have an edit mode that let’s you interactively play with blocks, and then a "save" operation at the end that generates text source back on the server. The model is that of dual-mode development (text view or interactive visual view). But I imagine it would still very definitely be distinctly for (a range of) developers. Consider the basic Laszlo system architecture, in which authorized source must pass through a central bottleneck server. By design, this isolates a group of approved developers to work (sequentially!) on an application. Even if you authorized "the world", the server model simply cannot scale out to support that many people making different versions of different parts of stuff. So there’s no way to reach a tipping point to break out of the "professional guild of developers" model. And given that, why even bother to make it easier for the guild? Do they really prefer to not use text? How will it change the economics of anything? Do companies (or consumers) really want for developers to do things a different way in order to be 10% or even 1000% more productive? [Mind you, I’m not saying components with reified behaviors are a bad idea for Laszlo. I’m just encouraging you to tell me what that would really mean.]