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.
HyperCard was Bill Atkinson's brainchild. Though influenced by a number of others, most notably Ted Kaehler, Dan Winkler, and Chris Espinosa, it was
Bill's vision, tenacity and willingness to go to the mat with John Sculley and even the board of Apple that got it out the door, over the resistance of Jean-Louis Gass�e and others who saw it as 'competing with our developers'. It was launched with a typical Apple PR blitz at Boston Macworld in 1987, and was also a centerpiece of the fall 1988 launch of Apple's first CD-ROM drive and its push towards mulltimedia. (The latter was my show; my role was producing large scale database and multimedia pieces with HyperCard to show off the CD-ROM and multimedia strategy, and get some developer momentum going.)
HyperCard always had a marketing problem of not being clearly about any one thing. Since it was initially packaged with every Mac shipped, it's likely the majority of buyers used it as a quicky Rolodex, if anything. But HyperCard's biggest win was a very low entry threshold for those who wanted to build their own 'stacks' - combinations of user interface, code, and persistent data. There were plenty of examples to suggest ideas, and all the code was open for tweaking. This did enable a burst of creativity by users, many of them educators and artists with no training in programming or database.
The proliferation of ideas created its own confusion. What was this thing? Programming and user interface design tool? Lightweight database and hypertext document management system? Multimedia authoring environment? Apple never answered that question. Probably the answer was 'yes, all of the above', and HyperCard could have been forked into several related products, each tailored to a specific market. But instead the forces against internal software projects won out, and HyperCard was shunted off to Apple's Claris spinoff, where it lost in the battle for attention with Filemaker and Apple/ClarisWorks. Several improved versions came out, but the code was never even completely ungraded to handle color displays, killing off interest from the multimedia and UI markets. Hard core supporters, particularly from the educational community, kept it alive when Apple reabsorbed Claris, but only on sufferance.
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. (To my knowledge there was never a study of programming usage and usability of HyperCard. A real gap.)
HyperCard also had its share of problems, particularly as a programming environment. Almost uniquely, every data element in HyperCard was a string. (Anyone else remember SNOBOL?). If you wanted another data structure, you built it out of strings, or expanded the programming language by adding in new compiled code primitive 'XCMDs'. The binding of code to individual cards and objects within them made it easy to create an unmanageable project with code snips splattered all through the stack, and many of the neophytes fell into this trap. Ditto the lightweight database had very weak identity and abstraction capability, another trap for the budding multimedia author. The tight binding of interface and data store also created weaknesses only obvious in retrospect: There was no cut line at all between client and server, and creating one was probably impossible in the original code base. HyperCard implemented everything in script code, even links. It was about as far from RESTian as you can get. If HyperCard had in some way mutated into an alternative to the Web, we'd be living in an even worse malcode Hell than we've got now.
So, adieu, HyperCard. I had a heck of a lot of fun with you (and the gang that birthed you), and I know others did as well. Your passing will leave a gap, particularly for the educators who still have no clear (and cheap) alternative. I hope some of the lessons you taught are passed on to new projects that allow just plain folks to try out coding and authoring.