Circumstances

When I give talks, I try to string together several themes -- some mostly in the visuals, others mostly in the script. My interests tend to fall between fields and my voice can sound odd, so threading themes together helps make sure that some of the people are amused at least some of the time.

The danger of multi-threaded talks, of course, is incoherence, and I think the RMIT talk strayed well into the neutral zone and perhaps beyond. Segues that looked fine on paper, earlier in the week, seemed impossible on stage. The audience was attentive and altogether gratifying, but perhaps it's because Australians are naturally that way.

One point I made in the talk that I haven't mentioned here, and should, is a surprising observation about prototype inheritance in Tinderbox. Early Tinderbox sketches had classes, not prototype, and we worried a lot that people would hate inheritance. Students, for example, notoriously find the notion of classes hard to master; being able to inherit from any object strikes computer scientists as wild and crazy but ought, in principle, to avoid this issue.

For whatever it's worth, though, Tinderbox users tend to make separate prototype objects rather than inheriting values from instances. While Tinderbox will let you say, "this note about War and Peace can stand as the prototype for all my bibliographic references", people tend to make a new note called "Books" or "protoBook" or something like that.

I do, too. But I don't think it's my influence at work; certainly, lots of people use Tinderbox in ways I don't!

So, prototype inheritance hasn't worked the way we expected. In some ways, perhaps, it's worked better than expected. But lots of people have discussed various inheritance systems and Tinderbox is probably one of the first applications of prototype inheritance in a context that doesn't expect you to have studied a few years of undergraduate computer science.