Still, there are some other things Hypercard did we’d do well to study, even with full-scale tools. Off the top of my head:
- It richly rewarded unguided exploration. Unsuccessful experimentation had a way of leading to paths forward, not just dead ends.
- Much of it worked by direct manipulation: if you want the thing there, you put the thing there. (Unity and Godot both sort of kind of do some descendant of this, but not with the same discoverability and transparency.)
- There was a rich library of good starting points, modifiable examples.
- An empty but functioning new project had essentially zero boilerplate. You didn’t have to have 15 files and hundreds of lines of code to get a blank page.
- Its UI made it easy-ish for newcomers to ask “What can I do with this thing here?” Modern autocomplete and inline docs kind of sort of approximate this, but in practice only for people who already have tool expertise.
- HyperTalk (the programming language) is tricky to write (it’s a p-lang), but it’s remarkably easy to read. You can peer at it with very limited knowledge and make educated guesses about its semantics, and those guesses will be mostly correct. (HyperTalk syntax tends to get the most attention when people talk about this, I think at the expense of the other things above.)
@jeang3nie@social.linux.pizza
