Why Hypercard Had to Die

Granted, that _may_ be a question of the tools. But I do find it telling that in the long time since the "death" of HyperCard nobody could come up with compelling tools.

And creating software is hard because ultimately, it requires analytical thinking. Which, by itself, is hard. Yes, the choice of tool modulates the hardness of the problem - but the underlying issues are still hard. (Note: I do not claim non-programmers _can't_ reason analytically. I claim the effort/result ratio is not right for them)

It's the same reason most people buy furniture instead of building it. Acquiring the necessary skill set is simply too much effort for the result.

- I think macro-recording etc counts as a trivialized programming environment

- Many standard desktop applications are programmable (though today point, they just throw in a pre-existing language) - Word processors (Word uses VB, .net; OpenOffice uses Java/Python; Adobe acrobat uses Javascript. I think you'll find in earlier word-processors (for eg), they had more limited programming environments, before that, not fully programmable scripting; before that, only macros, before that only specific and limited explicit configuration... and before that, no customization at all.

- Flash authoring tools can do what Hypercard did, and more; they are also very easy to use for simple things, and even do it in a similar way to hypercard (but include a full programming environment for more complex things, like spreadsheets do). NOTE: flash's programming abilities have been enhanced tremendously over the years. I don't know the origins, but I wouldn't be surprised if it initially didn't have a "programming" capability, but just customizing some aspects of playing movies.

- html + javascript itself is not that different from hypercard, especially if you include an "authoring tool", of which a great many exist.

- wiki's are also hyperlink based...

- online forms (wufoo, google forms) - they derive a database from forms (like ORM, but skipping the objects, to be "FRM"), and include constraints, different paths, and reporting tools.

- vim has a programming language, but it's about as pretty as programming with a spreadsheet. This is because it evolved from something simpler, to get specific tasks done - I don't think vi was programmable! certainly not in the earliest versions (emacs is the exception, beginning with an actual programming language). I'm not even sure that shells were initially programmable for that matter... and that's about as close to a programmer as a tool can get.

[Also please check my follow-up comments, esp: visicalc was not initially about programming.]

---

TL;DR I put it to you that any tool can have automation added on to it - and if we view it this way, "trivialized (or specialized) programming environments" are the norm, not the exception. Their goal is not "programming", but to solve the specific problems and meet the specific needs of their users. But the natural direction of a customization/configuration is programmability (and then to add programming features to help manage complexity, e.g. libraries, namespaces etc). It might take a while to get there. Some instances we see are only part-way there (see above); some stop growing/die before becoming attaining that level of customizability.

Going back to flash, ActionScript 3 added optional static types, enabling dramatically faster performance; before then, it was a version of Javascript; before that, it was a kind of hacked together script thing. I don't know what they had way back in Flash 1.0, but I suspect it wasn't yet programmable... just as visicalc 1.0 wasn't programmable...

But it's definitely a niche product, which we've seen isn't something Apple is interested in. Supercard.us is down right now, so I'm not sure whether it's on the market or not. As Apple has discovered, the vast majority of computer users aren't interested in creating software; they're content consumers. SuperCard probably got as much use for making quick mockups before building a "real" application as it did by amateur developers.

One thing that I'll give HyperCard is that it made it easy for me to play around with programming while I was in elementary school. Today's programming tools are largely not that accessible.

* All the cards in a given stack must be the same size, even if there are several different backgrounds in the stack.

* Smallest card size: 64 x 64 pixels

* Largest card size: 1280 x 1280 pixels.

You're right: HyperCard and Excel aren't a small set of interoperable tools like UNIX is. I would argue, though, that they are close: a walled garden of interoperable tools. Rather than guide you through steps to a specific end (the extreme example is a wizard for, say, a mail merge), they present you with tools you can use to get to that end. Obviously, they don't work particularly well outside their garden, and the great advantage of adding tools to your toolset is cumbersome at best.

I do wish I understood the UNIX philosophy better. Perhaps I'll learn more over time.