This doesn't seem to be anything special about Hypercard.
Hypercard was the BASIC of the Macintosh in that it served the same niche. It certainly was not BASIC, but the idea was the same, a little language and environment that fit into the machine's environment that allowed novices (and then highly practiced novices :-)) to create stuff on the machine for other people to use.
It was killed for the same reason BASIC, in the sense of built-in 8bit micro BASIC, kind of fell to the wayside except as a way to stitch existing apps together. No one is really impressed by a calculator program anymore. Matching the capabilities of modern software is hard nowadays. It's demotivating to create a calculator program... that's it? Hypercard really can't match even JS, et al. in functionality.
I remember when it started to happen in the 16bit era. Software was already starting to get too good and too complex for a simple tool. I got an Amiga. The Amiga had a built-in BASIC -- but no one used it. Why? Because there was no fucking way you were going to recreate even the bouncing ball demo in BASIC. It wasn't going to happen. Essentially, anything you created was going to be a huge disappointment with that tool. This was not necessarily true in the 8bit days -- but from 16bit on, you either learned assembly/C or gave up. People can learn in that environment (and did), but the barrier was much higher.
Lowering that barrier while coming close to the capability of "real" software is a hard problem. Fortunately, it's coming full circle. Now that machines are powerful enough that "real" software is being written in interpreters, JS seems like it actually is the new BASIC.
I'm not totally sold on that -- because the stack is too too baroque (although, again, people do learn in that environment). Processing is perilously close but not quite there because it's so domain specific. Python comes with a lot, but doesn't fit into native environments very well. If I had to chose, I'd say it's going to be something else over the JS/CSS/HTML stack in the same way 8bit BASIC sat over the primitive OS at the time.
I wished Hypercard was the BASIC of Macintosh. However, when I tried to build something with it (a manager for the offline game Car Wars), I quickly ran into some trivial obstacle, and was told that I'd have to write a C extension. (iirc, it was the lack of a random number generator.) Enough of that.
Hypercard was mostly useful as a sort of personal wiki or address card book; I used it quite a bit as a notepad with hyperlinks. It didn't die for any real dramatic reasons. It was programmatically stuck in the 9" B&W Mac era and never quite fit onto larger color screens, so once the web came around, Apple dropped it.
Also you history is way off, because BASIC morphed into VisualBasic, which did everything Hypercard could and ten times more, and was the leading programming environment for a generation.
Similarly, you had to do a lot of peeks and pokes in most 8bit BASICs to really get at the machine. But you could still do something reasonably worthwhile. I don't want to imply that you could do everything. The main idea is simply that you could do quite a bit, and it really did look and feel decent compared to apps of the day. As the systems got more advanced, it became harder or perhaps just less of a priority to empower your average novice.
I've never thought of VB being for an ordinary joe in the same way builtin BASICs were -- it was more of a macro language for Office, and a platform specific COBOL, not an entry-level environment. But I don't have enough direct experience -- perhaps I'm wrong about that...
I agree. The web stack is a castle on a swamp, except that swamp is itself built above a hyperspace junction linking everything in the world together.
The web surpassed HyperCard from day one, simply by locating its resources on the network. And that's why people put up with it, even if we have to dive into a fetid quagmire every time we use it.
HyperCard versus the web is a classic example of Worse is Better.
Is it not programming because the syntax is verbose? I don't know anything about hypercard, but from the example in the OP it just looks like a limited and clunky IDE with a toy programming language. Just enough to build things that are just about good enough for people with limited goals, but then again there are thousands of products like that out there.
The whole paranoid 'everybody conspires against it because it's so great' is bullshit. If it's so great, why hasn't anyone make a clone and got rich of it? It's quite obvious why: because everybody who uses it runs into its limitations very quickly, so clones add extensions, and after a few iterations it becomes too difficult for beginners. And then the next clone stands up, lather rinse repeat.
That rant is was quite nice... had me going for a minute.
But I'm sure it is one of many in a line of "reasons the software crisis didn't have to happen" - riiight. The "mythical man month"? It's 'cause they didn't do it right in 1960/1970/1980/1990/2001/... If only "they" would learn...
We agree much more on what's "right" than you suggest.
Take two systems which do the same things. One does it as expected, the other surprises you in subtle ways. One does it as specified, the other sometimes does not. One does it quickly, the other makes you wait a bit. One fits in a few pages of code, the other takes a whole book.
I agree that you can't tell what's right in advance. But it's not a matter of preference, it's a matter of ignorance. In hindsight, when you see the results, you can most of the time point out what could have produced better results, if only you knew. You can even go meta, wondering why you didn't knew, then try and change that in the future.
I upvoted you because I think this is a conversation that should be as civil as possible. My original tone was probably a bit too sarcastic.
On the subject of "doing it right" - every software engineer or maybe most passionate software engineers, have an ability to look at a spec or a piece of code and see how it is "done right". I certainly have my conception, my agenda, of what the right way to code and good software engineering is.
The thing is that this comes after fifty years of efforts to "do it right" failing in the sense that we don't have a single language we're satisfied with, we don't have a single operating system people unambiguously call good etc. The edifice of modern computing seems to lack a sound foundation.
The grizzled software engineer often knows this as a fact without caring about why and indeed the why is obscure.
Oddly enough, I think can illustrate my explanation for "why" by noting the common complain that programmers are "constantly reinventing the wheel". Now, if we look at the automotive engineers who build cars, we will note they too are "constantly reinventing the wheel" (literally now). Yet no one complains that the automotive engineer must create a new wheel for a new car with different mechanical properties than the old car which had the old wheel. Here we can see problem and the solution ("reinventing the wheel") does not seem intuitively to we-humans as a problematic state of affairs.
Looked at this way, initial criticism of a software engineer "reinventing the wheel" is a bit ridiculous. It seem logic that an engineer needs to change the components whenever they are putting together a different system for a different purpose. Moreover, the variety of distinct circumstances a software system needs to be engineered for is vast - it faces far more meaningful-context-changes than a car. In this perspective, it is absurd to expect the
Yet, this intuitively, with our human intuition, just doesn't seem right. I would claim that the intuition we have involve a natural conflating of something like "the idea of a wheel" with "the software implement of a wheel". A software implementation of a wheel or anything is more nebulous than a physical wheel but it is still not "the idea of a wheel". But as we "naturally" conflate these two item is easy for us to believe that we only need to think up the concept of an entity and we will have captured the thing. And this natural conflation of the ideas is perhaps where things go wrong... Where we get off expecting "general purpose operating system" to satisfy the gazillion purposes assigned to it, etc.
You're completely missing my point. I'm actually sort of agreeing with you -- but I'm also saying you don't really need (want?) to duplicate Hypercard.
Let's just say that considerably more than "thousands" have written BASIC programs that were real useful applications in their day. I would not argue that people have not done the same in Hypercard.
There's nothing special about hypercard. What's special is having an easy-to-use beginner programming environment that you could create fairly good small programs in -- in comparison to the commercial offerings of the day. BASIC was that, Hypercard was that, but that only partially exists today as the web stack because of it's baroque nature.
"Foundations matter" is really a tautology. I don't think the problem is the foundations. We build on sand all the time. Certainly without a foundation, you're fucked, but you place too much importance on it. Saying something like "Foundations matter" is pretending to be profound without substance. I might just as well say that "Input devices matter" -- and they do -- but how much do they matter? Is everything fucked because we all use mice & keyboards?
Yes, I read your article. I think I understand where you're coming from, but it's completely circular. All you need to do is create another mostly impermeable strata. People do this all the time, and it has been wildly successful so far.
In that sense, original foundations don't matter. But, of course, they do, 'cause you had to build a new strata, right? Round and round...
And, in the passing of time, you can simply replace the underlying foundations with something more unified. This, again, happens all the time. CPUs gain SIMD instructions and new addressing modes, VM support, etc. I fully expect, while nothing like DESCRIPTOR, more hardware support for higher level GC to come if its worth is proven.
The input device remark was probably a poor analogy, but it is somewhat similar. "Input devices matter". Well, duh, yeah. But it certainly is not a good summary of an argument to replace the mouse and keyboard with an generalized gesture recognition device. :-) The mouse was an addition to the keyboard, not a reconstruction of it. If we find that, say, speech is better at some things, we don't propose to take away everything else. We build on top, because, while it may offend the sensibilities of some -- you can fix the warts later.
You're right to say that we're all working on huge 8bit micros to an extent -- but beyond the historical implications, it's circular to think that really matters. It's why Alan Kay now sounds like a grumpy old man, as Raskin does, as most people who moan about lisp machines and the DESCRIPTOR architecture. Today, I can run emulations of these things far, far faster than the originals and the software on my box is far more capable than the software people were using then. The real world favors cutting away/polishing a turd into a smooth stone, not piling up someone's perfect diamonds -- because restarting from scratch every time you discover something new is wasted work.
HyperCard was one of the most influential programs in history. Consider it was released in 1987 and ran in 1MB of RAM. It had four major impacts:
1) It was a concrete implementation of the idea of hypertext that actually worked. The fact that comments in HTML begin with <!-- is a tiny little ode to HyperTalk.
2) It was the first graphical IDE that I know of. (Clunky? At the time -- 1987 -- it was glorious.)
3) It was one of the easiest programming languages to pick up, if not the easiest, and yet it scaled to become quite powerful. (There was eventually a native compiler, itself written in HyperTalk, that could even create INITs.) HyperTalk's ease-of-use led to blind alleys (AppleScript tried to one-up HyperTalk and ended up being "read only").
4) It was extensible via plugins.
It was also an incredibly productive programming tool. In addition to allowing novices to code, it let me -- for example -- implement an RDMS engine in an evening, and build a database application (including reporting functions) in a second evening. It allowed the Millers to create Myst (they used a couple of plugins, one to display color images).
But HyperCard was written by a lone genius (Bill Atkinson) with weird quirks and flaws and it was impossible to maintain or improve. Its notable flaws included:
a) Weird code-base. It never really got a version 2.0. This is probably its single biggest flaw since all the others are things you'd have expected to be fixed in later versions. (Yes I know there was a version 2.0, but aside from a new debugger and plugin interface it wasn't a big improvement and it was slow coming.)
b) No native support for images. Visual Basic would address this by allowing you to treat images as just another kind of variable and manipulate them directly.
c) No native support for color, and 1-bit graphics were built into it in a very hard-to-fix way. Indeed, HyperCard was rewritten from scratch for the Apple IIgs and worked fine in color, but the Mac version never did.
d) No support for native controls. All of HyperCard's controls were faked and looked wrong. (And this flaw was faithfully copied by HyperCard's many imitators -- such as SuperCard, Runtime Revolution (still going!), and Assymmetrix Toolbook.) Again, VB addressed this.
e) No ability to create true standalone applications. Once again, VB addressed this.
HyperCard wasn't killed by Steve Jobs. It withered on the vine and Steve Jobs simply took it off life support. As for the other stuff he killed -- yeah, some of the dead-end Lisp-based projects that hadn't already been killed. No conspiracy -- HyperCard just wasn't fixable and by 1997 it didn't matter any more.
Several HyperCard clones went on to be pretty successful. Macromedia Director came into its own when it copied HyperTalk (which became Lingo). Visual Basic was in essence an improved HyperCard but with a crappy language. (In every head-to-head test I tried between VB3 and HyperCard, HyperCard hugely outperformed VB3, which if you know anything about HyperTalk is pretty sad.) And then of course there's the whole web thing.
SuperCard is one clone that picked up where HyperCard left off, with the extremely similar SuperTalk language. It fixed a lot of Hypercard's issues, like built in color support, access to native UI widgets, multiple windows, and the ability to create standalone applications. Updates added both OS X and Intel compatibility.
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.
Good of you to mention SuperCard which was, in many ways, the obvious successor to HyperCard (and it was revived a few years back and died owing to lack of interest). These days Runtime Revolution fills that niche. SuperCard was kind of flaky (I developed some stuff with it) and, more importantly, took an IDE -> shipping app model (where the dev environment was pretty much split off from the standalone app). This made it more useful for "real programmers" but less accessible for tinkerers.
It's probably worth mentioning that HyperCard was incredibly stable. You could work in it for months on end without crashing or losing any work. That alone was pretty staggering for the time.
Hypercard was the BASIC of the Macintosh in that it served the same niche. It certainly was not BASIC, but the idea was the same, a little language and environment that fit into the machine's environment that allowed novices (and then highly practiced novices :-)) to create stuff on the machine for other people to use.
It was killed for the same reason BASIC, in the sense of built-in 8bit micro BASIC, kind of fell to the wayside except as a way to stitch existing apps together. No one is really impressed by a calculator program anymore. Matching the capabilities of modern software is hard nowadays. It's demotivating to create a calculator program... that's it? Hypercard really can't match even JS, et al. in functionality.
I remember when it started to happen in the 16bit era. Software was already starting to get too good and too complex for a simple tool. I got an Amiga. The Amiga had a built-in BASIC -- but no one used it. Why? Because there was no fucking way you were going to recreate even the bouncing ball demo in BASIC. It wasn't going to happen. Essentially, anything you created was going to be a huge disappointment with that tool. This was not necessarily true in the 8bit days -- but from 16bit on, you either learned assembly/C or gave up. People can learn in that environment (and did), but the barrier was much higher.
Lowering that barrier while coming close to the capability of "real" software is a hard problem. Fortunately, it's coming full circle. Now that machines are powerful enough that "real" software is being written in interpreters, JS seems like it actually is the new BASIC.
I'm not totally sold on that -- because the stack is too too baroque (although, again, people do learn in that environment). Processing is perilously close but not quite there because it's so domain specific. Python comes with a lot, but doesn't fit into native environments very well. If I had to chose, I'd say it's going to be something else over the JS/CSS/HTML stack in the same way 8bit BASIC sat over the primitive OS at the time.