I think much more likely explanations than the nefarious anti-creative one given for HyperCard's death are that, to varying degrees: Steve found all HyperCard stacks he saw to be messy and confusing, not at all the functional simplicity he was looking for; HyperCard was taking engineering resources and/or money that could be better spent saving the Mac, and therefore Apple.
Apple has not, in recent years, on the Mac, been against trying to provide simpler programming environments - look at Automator, (the now also defunct?) AppleScript Studio, or Dashcode.
Simple programming environments have a fundamental flaw: they fool you.
Let's say we have a type of perforated balsa wood that you can just snap into pieces and glue in place. Making a dog house just went from hours to minutes! Hurrah! So you start telling everyone that this is the new way to construct buildings, but then as you get bigger structures, it starts to fall apart.
Simple programming environments fool you into thinking you into thinking your projects can scale, and the result is a mess. Hypercard was fun, but it wasn't a deep paradigm, it wasn't good syntax, and in the end, I have to say that it was good that it died.
Very good point. I think spreadsheets are just deep enough and map well enough to the domains that use them, that it can tread water. (Not swim, mind you.) They're also quite clear about their constraints.
Of course, from a software engineering perspective many things that are developed using spreadsheets are truly horrific - but the non-developers who create complex systems using them love them.
Spreadsheets have a much more brilliant potential than we currently understand. In fact, it's my opinion that in the future we'll be essentially coding in a spreadsheet; not a text editor. (That's the case with the project I'm working on.)
If you want to talk about this more, I'm david927 at gmail.
Simon Peyton Jones et al. wrote an interesting 2003 paper on extending Excel's "natural" mapping to functional programming with first class (i.e. cell-based) user-defined functions.
If less of our finance system depended on spreadsheets and were actually well understood and observable by properly designed software, the 2008 crisis could have been averted.
>It's good that it died because it doesn't "scale" to the elephantine size of software you're accustomed to?
As someone who's dealt with accounting systems that have started out as Access + Excel + VB Macros, I can say yes, absolutely it is a good thing that it died because it didn't scale.
I was a fan of Hypercard all those years ago. But, in my opinion, that combination: lack of depth + poor syntax, it just wasn't a strong enough contender. It could be kept as an introductory technology, but even there, we can do better. The same fate happened to VB, Actor, Object Vision, Omnis, and so many others. It's a cold world if you can't keep up.
But notice that list. It's all efforts from the 80's and early 90's. We gave up at some point. There's no excuse for that. Shame on Apple, and everyone, for that.
Maybe I'm being too hard on Hypercard, but that criticism is only about that particular technology -- certainly not the effort as a whole.
> It's good that it died because it doesn't "scale" to the elephantine size of software you're accustomed to?
Does nobody else find this hilarious? I mean, the whole persecuted-Mac-fan vibe here; it's so 1990s it's almost a time warp in itself, except this time it's a persecuted-Classic-Mac-fan, and the main entity doing the persecution is Apple itself.
Apple has not, in recent years, on the Mac, been against trying to provide simpler programming environments - look at Automator, (the now also defunct?) AppleScript Studio, or Dashcode.