When something new comes along, we tend to describe what it is. If it's something important, it takes a while to figure out why it's important – what it is that is really different. The description of what something is tends to be somewhat dry and technical and it misses the point. For example, a telegraph is an encoder and a decoder in an electric circuit. But couriers and semaphores involve coders and decoders, and other stuff has had electric circuits. What was important about the telegraph was that it provided instantaneous long-distance communication. This is also what was important about its successors like the telephone and radio, even though the descriptions of what each is are quite different than that of the telegraph. It's not as simple as describing what a new invention does for people. Quite often we don't know how it will be used.

Since I first heard about Croquet, I've been trying to figure out what is really important about the immersive 3D that everyone first notices about it. I think I now have an idea. It turns out that the “immersive” part is key.
[Read More!]

I don't know why software projects need meaningless codename, but they do. Maybe that's how this ethereal stuff becomes “real.”

I can't say that all our U.Wisconsin projects for Croquet will be named after cheese, but I wouldn't be surprised. Not sure why Wisconsin means cheese, yet we start with a French cheese. But Brie is cool. My wife lived there for a while. The have big parties when the new cheeses come out, but you can also buy this old wrinkled stuff that you can't get here, which my wife calls “fromage morte.”

So, what is Brie? [Read More!]

I had hoped to have a usable version of the components framework by now. Instead, I have a reasonably self-consistent set of scaffolding that illustrates a lot of the concepts. It isn't at a critical mass of functionality, and it has a lot of bugs and mis-steps. I was sure that copy semantics, multiple views, and event handling were going to be hard, as would getting enough corners tacked down so that I could start to cut the cloth. But they turned out to be much harder than I imagined. Nonetheless, I've now got a stake in the ground as the starting point. Maybe now there's enough 'it' there that I can next report, “made 'it' do such-and-such”, or “added X to 'it'.”

Below the fold is a diary/log of how I got to this point. (I originally called this a “bootstrapping” architecture, because components allow people to build their Croquet models from within Croquet itself.) [Read More!]

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. [Read More!]

The component model I'm working on tries to make everything you deal with visibly concrete so that it can be directly and uniformly manipulated — even behaviors. It was inspired by my wife's fascination with a game on her PDA. [Read More!]

The computer spreadsheet doesn't get enough credit among computer programmers. I think that more than any other one concept, VisiCalc, 1-2-3, and Excel were the killer app for the personal computer. As a programmer, I have tended first to think of formulae and calculation mechanisms when I think of spreadsheets, but the UI and development style are perhaps more significant. For each individual cell, you can look at the value, the formula, or the formatting, and change each through a menu. You can incrementally build up quite a complex application all on your own, never leaving the very environment you use to view the results. Why doesn't all software work this way, only better? That's what I'm working on. [Read More!]