Hypercard had a really nice programming language with automatic formatting and (eventually) an excellent debugger. The code was both easy to read AND write, and

Hypercard had a really nice programming language with automatic formatting and (eventually) an excellent debugger. The code was both easy to read AND write, and it was pretty easy for a competent programmer to understand clean up dodgy code written by a novice. The view hierarchy was very simple: card controls, card, background controls, background. And the event hierarchy matched it and added a couple of higher levels. All variables were strings. (This turned out to be a significant problem when it came to adding features.) At a time when string manipulation tools in most languages was quite hard, it was insanely easy in HyperCard (e.g. the concept of "split" was intrinsic to the "chunk" system for string manipulation). The environment itself was incredibly stable, and by default all your work was persistent and everything you did was persistent (making things volatile was extra work). E.g. if you changed the name of a button with code, the name change stayed. By the same token data and code lived together in this persistent world. It was all based on direct manipulation. Want to create a button? Draw a button. Want to change its script? Command-option click on it OR go into edit mode and double-click on it. The drawbacks of HyperCard were more interesting, especially since efforts to produce third party replacements usually managed to address "obvious" shortcomings, while losing key bits of magic (e.g. stability). Years after moving away from HyperCard I did a bit of Toolbook development -- of all the HyperCard clones I tried, it was probably the best (and certainly addressed a lot of HyperCard's shortcomings).