Given that HyperCard is often cited as an positive...
# thinking-together
b
Given that HyperCard is often cited as an positive example of a desired end-user programming experience, I found it interesting to discover that Bonnie Nardi was not so fond of it. In her discussions of end-user programming, Nardi believes that domain-specific programming systems succeed when they implement the domain-specific concepts that domain experts already know. To perform non-trivial tasks, HyperCard requires that users learn HyperTalk. But HyperTalk, rather than embodying domain-specific concepts, is instead essentially an ordinary general-purpose programming language but without the speed or flexibility. Bonnie A. Nardi, “A Small Matter of Programming” (1993) p53:
What about HyperCard? HyperCard with HyperTalk is a compromise between a general programming language and a task­-specific language. HyperTalk doesn’t do everything that a general programming language does, but it does provide a friendlier syntax than, say, C++. Like spread­sheets, it is interactive. But there is very little in the way of serious commercial stackware. To create stackware or applications that are not simple prototypes, users are faced with learning HyperTalk, which is almost as complex as a conventional programming language and requires mastering basic computer science concepts. The problem may be that HyperCard­-like environments are actually a bad compromise: they have the complexity of conventional programming languages but lack their speed and they are not close enough to end users’ needs to provide the right kind of task specificity, nor are they general enough to be as powerful as a conventional language.
j
Disagree. Nardi is missing that HyperTalk is a self-contained programming world optimized to work seamlessly within HyperCard stacks. A general language would add an awkward and complex API for doing everything. Plus a general language depends upon a giant stack of other technologies: libraries, packages, editors, debuggers, compilers, OS, etc etc. To be fair, the tech stack was a lot smaller back then.
👍 2
🤔 1
j
I loved HyperCard as a kid. The learning curve for HyperTalk was gradual and not too steep. The HyperTalk books had fun and detailed example code. HyperTalk led me to learn Lingo in Director and ActionScript in Flash, which were both very similar to it. And then a bit later JavaScript, which was very close to ActionScript and the later versions of Lingo. And even now, 25 years later, I’m still coding in Javascript — so I haven’t gotten too far, I guess 🙂.
🍰 2
b
@jonathoda Having a self-contained environment is probably a good idea, and an idea worth copying. But Nardi’s null hypothesis is spreadsheets. In whatever domain HyperCard targeted, it didn’t see the same kind of success that spreadsheets have had in their domain—why? I interpret Nardi’s criticism is that HyperCard didn’t have a well-defined niche and so it didn’t fill it fittingly.
👍 2
j
People were doing all kinds of things in HyperCard that you’d use specialized tools nowadays for: databases, hypertext, multimedia, ui prototyping, drawing, etc. Many of them required just a little HyperTalk, or none at all.
j
But in retrospect, HyperCard was a great success, spawning a cult following. It seems foolish that Jobs/Apple killed it. I guess things looked different back then — perhaps they were expecting the next spreadsheet. After all these decades without a next spreadsheet our expectations have lowered.
👍 3
j
Bill Atkinson, the original creator of HyperCard was an idealist, like many at Apple — which is an interesting contrast to the commercial spirit of Jobs. Atkinson wanted HyperCard to be free, so I think he took a leave from Apple to develop it and sold it back to Apple on the condition that it was shipped for free on all Macs.
And I think the first version was shipped for free, but then later on Apple made the player and the authoring tools separate.
The development stalled — I don’t think there was ever a decent version of HyperCard with colors, for example (only via clunky XCMD addons). And when display sizes became larger, one would have liked to have resizable windows, for example, which HyperCard didn’t support at all.
So I think there are a number of historical reasons, too, for HyperCard’s failure. But even nowadays marketing something as multi-purpose as HyperCard would be hard.
☝️ 1
k
I think there is a place both for domain-specific tools such as spreadsheets and for less specific tools such as HyperCard. The "end user" is not a sharply defined profile, and many application domains are not so well defined either. I am personally more interested in HyperCard-like systems for "power users", because that's the most common profile in my own field, which is computational science. But I would definitely like to see better tools for "real" end users as well.
g
If Hypercard is so awesome why hasn't someone cloned it and made $$$$$$$$$$ I suspect the true answer is it's only awesome in people's memories, not as much in reality. Maybe I don't know it that well. All I really remember is you could make a stack of pictures and hot spots that lead to other pictures in the stack, the end. Anything past that required scripting.
w
Worked for Myst...
g
Myst IMO is not a good example. It was an extremely simple idea with amazing graphics for the time. Basically right place right time. Try it today and I don't think you'll get quite the same reception, though as all entertainment it probably depends far less on the tech and far more on the writing / star power / perception.
w
The technical accomplishment in Myst was the authoring of assets (especially the little Quicktime videos). The artist one was the mood and setting. Hypercard's role was to stitch it all together.
j
I don’t think HyperCard as such would work well nowadays — it was already outdated when it was killed in 1996. But I think there are still things that one could learn from it.