Due Diligence: A Eulogy for Hypercard:

To the surprise of few, Apple's Hypercard passed away quietly this week, after life support was finally withdrawn by the company. It had a run of over 16 years - though the last were in circumstances of at best benign neglect. Not a bad duration for a software product, but it still hurts to see it go, since I had some part in its gestation.
...
From a software architecture point of view, HyperCard had a number of interesting ideas which might bear reexamination. At a time when persistent object stores were still novel, HyperCard was built around one. It's not going too far to say that its user interface was simply a reification of the object database. HyperCard's programming model was object-like, but didn't fall neatly into either the class/instance or delegation styles. Individual visible cards in a stack were created as instances of prototypic backgrounds and could be pre-populated with text fields and action buttons. Default message passing was an odd hybrid of visual containment and fixed object hierarchy. These features, plus a very texty scripting language, seem to have made for a very approachable tool for the nonprofessional coder or database creator.

Now Groove, which has the most awesome distributed object store I've seen (it's XML, too). The programming model, like a lot of things in Groove, is inside-out compared with many previous approaches. Notes began with list-oriented @functions, and grew to include Lotuscript, then Java (and JavaScript). Groove began with C++, then script, now .NET and web services... and, some day (soon?) it'll become as accessible as HyperCard ever was. Roll on.