“Apple never again brought to market anything resembling HyperCard. […] The reason for this is that HyperCard is an echo of a different world. One where the distinction between the “use” and “programming” of a computer has been weakened and awaits near-total erasure. A world where the personal computer is a mind-amplifier, and not merely an expensive video telephone. A world in which Apple’s walled garden aesthetic has no place.”
I didn’t understand what he meant by the weakened distinction between user and programmer, but in another blog entry he explains it as:
“The distinction between “user” and “programmer” is an artifact of our presently barely-programmable and barely-usable computing systems.”
So his point is, that as far as HyperCard is concerned, you are neither a user nor a programmer, you are an operator. In contrast to today’s developers and users, operators are more independent and self-sufficient, operators create the software they want to use.
Today’s users depend on programmers to provide them with tools; users just passively adjust to what they get (think of iPhone apps). Today’s programmers make money by being the high priests who keep the secret of “making stuff work”; programmers are not interested in creating competition by making it easy for users to become programmers themselves.
What would happen if a big company decided to cater to operators? In a world (and economy) full of operators, empowered by a hypothetical modern-day version of HyperCard, companies would lose some control and market opportunities: It’s hard to sell a custom shop database to operators who can “roll their own” (or can easily find a neighbor who can).
Possibly HyperCard was successful because it ran on relatively simple and small systems, and only therefor it was easy to learn. Could such a simple concept scale to today’s mesh-ups of networks, databases, mobile devices, web browsers, and web services? HyperCard was well integrated into its OS (it was practically a Mac’s commandline interface — remember the message box?). To revitalize HyperTalk, its API must be able to reach out to all these new components consistently.
AppleScript tried and failed to be as user-friendly as HyperTalk: I recall I spent hours tweaking one line of AppleScript code that tried to reach an embedded field inside another application: Something like “put blah into line 5 of the content of field A of panel B of element C of window D of application E”… I gave up because, without API documentation or automatic code completion, it was impossible to drill down and reveal all the required layers of the external application. To be able to compete, a modern HyperCard would have to be able to deal with the increased depth of modern PCs, where applications may be spread over networks and frameworks, without losing its simplicity. Platform independence is quite a challenge, as we see today with Java.
As opposed to Java and Linux, the original HyperCard was never open-sourced. The HyperCard community eventually splintered and fizzled out after various unrelated (and unsuccessful) attempts to recreate the former glory. Would open-sourcing it have prevented that? Did we miss our one-time chance for an über-awesome HyperCard-Linux hybrid…? :-o