Hypercard was a thrust in the direction of the Engelbart/Kay/Papert vision of personal computing, one where there wasn't so much of a division between "programmers" and "users" (Hypercard users were even called "authors"!) This vision of computing has fallen out of fashion for a few reasons, and it's a real shame. We have, instead, allowed our personal media to become arcane devices of dubiously "necessary" complexity. You can see this in any cafe where a web developer is using a teletype emulator to create a UI, or when someone cannot take the logical "next step" in processing some information in their spreadsheets (like retrieving data easily) because the system is not set up to allow them to explore that possibility without first learning a full fledged programming language top to bottom.
One lesson from this Kay/Papert line is that, when it comes to personal computing systems, metaphor is key. Hypercard worked in large part because the metaphor of cards, stacks, and live objects acting on cards and stacks was highly intuitive to a lot of people. Add in the fact that you "do Hypercard" in Hypercard itself, and that the home stack is itself an explorable example of how the whole system works. Imagine if web developers could work this way, making their sites and applications in the browser. Good luck copying and pasting that button!
> Hypercard was a thrust in the direction of the Engelbart/Kay/Papert vision of personal computing, one where there wasn't so much of a division between "programmers" and "users"
I couldn't agree more with this conception, and I wish that philosophy was more widespread within our industry. Sadly, it seem that the predominant philosophy is the opposite: users are mere consumers, cattle really, who should be grateful their programmer masters deign to provide them anything.
Lots of good thoughts! I ended up at constructionism: https://en.wikipedia.org/wiki/Constructionism_(learning_theo... and wonder if perhaps that is a key concept? The points about metaphor, authoring and others in your reply are significant as well. As a contstructionist, my next question is how to build a modern hypercard? What would that look like?
Constructionism seems to be one of Kay's sticking points -- this is one of the ways children can learn best (but what about adults?)
Obviously a modern Hypercard cannot simply be a contemporary reimplementation of Hypercard, with extended APIs for the online world etc. That, in fact, exists and it's called Livecode.
What was great about the later versions of Hypercard is how they fit holistically within OS8/9. You could interface with Applescript and access key APIs in the rest of the operating system in the plain way. What really should have happened next is that many of the basic applications should have themselves been implemented in "a hypercard" For example, imagine a Finder that let you peek under the hood to see all of its scripts and, after some kind of "unlocking" allowed you to change it. You get access to a lot of the power of the OS's API for free at that point, and users can easily figure out how to script something like a "every three days move files from here to there" or something.
The switch to Unix also meant a switch to and older, more complicated, less intuitive bundle of methods for system scripting. Useful UI metaphors go away at that level and are replaced with bad and outdated metaphors, like the teletype. Leaving aside things like Applescript which have been largely left to die on the vine, personal computing operating systems seem to have regressed from the contructionist perspective.
I guess what I'm suggesting is that you cannot have a "modern hypercard" without having a different kind of operating system, which itself might require a different hardware architecture.
An ideal system would be "layered." For example, at Layer 1 you have "a hypercard" and most of the GUI, including Finder-like things, windows, basic buttons, can be manipulated easily at this level. Users can also peek. But one they reach the limits of that high level hypercard system, then can "peel back" a layer and are introduced to lower level APIs and a new language. It has access to all the same objects and APIs as the hypercard layer, but in a different way, along with more APIs that were previously invisible. You could then have a third layer that is the systems language and APIs at the lowest user accessible level -- this is where "professionals" would live, but because it would be exporable and "peel back-able," determined users could get there by example.
Something like a lisp machine at layer 3 that runs a smalltalk at layer 2 that runs "a hypercard" at layer 1 would fit the bill. But take those as analogies.
I've come to a variant definition of constructionism, based not as a way to learn, but construction as a way to explore/understand. Especially when being entrepreneurial, analysis only takes you so far. In one of the YC video things someone said something to the effect that in Silicon Valley more people tend to talk about "what if you could?" rather than "why you can't", which sums it up for me.
The best example of a constructionist approach I can think of is complex adaptive systems (CAS)- the way to understand a CAS is to build one, taking one apart only gets you so far.
I see where you are going about the lisp and I like that! What a cool idea! lispercard? :-)
One lesson from this Kay/Papert line is that, when it comes to personal computing systems, metaphor is key. Hypercard worked in large part because the metaphor of cards, stacks, and live objects acting on cards and stacks was highly intuitive to a lot of people. Add in the fact that you "do Hypercard" in Hypercard itself, and that the home stack is itself an explorable example of how the whole system works. Imagine if web developers could work this way, making their sites and applications in the browser. Good luck copying and pasting that button!