Live data from Hacker News

Why Hypercard Had to Die

loper-os.org

111–120 of 142 posts

Re: Why Hypercard Had to Die

#111
post #16

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,…

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 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.

Re: Why Hypercard Had to Die

#112

Earlier quoted context omitted.

I don't think the calculator was intended as an example of a great program, or of the "potential of a computing environment". I think it was intended to be a very straightforward example of something that anybody could make as a practice project in HyperCard. If you're new to programming, "make a calculator" is a great project. It involves simple math -- which you probably already understand -- simple operations, and…

It also illustrates some of HyperCard's strengths. I can't think of any other development environment in which "make a calculator" would be a suitable project for the end of the first week of a programming class. Visual Basic 3? What we have instead are mysterious black boxes, and I hate that. But, I'm on the end-user support side of things. Here, let me give you some examples of stuff we've dealt with in our little…

Yes, but it's a fallacy to think I could practically do anything about it if only it wasn't so black box like. Do you really have time and motivation to become expert enough in all the things you deal with that you could fix any problem if only it was more explorable?

I think it's a fallacy to say you'd need to become an expert in all the things you deal with to benefit from the openness; you just need one person to fix it and distribute the changes. How many users benefit from CyanogenMod due to Android's openness, despite having never touch the source?

Re: Why Hypercard Had to Die

#113

HyperCard like systems are not dead. I make my living from LiveCode ( http://www.runrev.com ) which is a xTalk system that is able to build applications for Mac OS X, Windows, Linux, iOS and Android. From a single HyperCard-like environment, I can build apps for all these platforms and reuse the code. LiveCode is very verbose and it may take a while for those that are already familiar with C-like languages but it is…

oh... I forgot to tell, LiveCode can import HyperCard stacks... =)

Re: Why Hypercard Had to Die

#114

Actually has a really good example (a calculator) to show how HyperCard could be used. HyperCard was a big part of my junior high years. It could even be extended, e.g. there was one add-on that allowed color graphics to be displayed and I learned to make some simple games that way.

But its not a good example. You're sitting at a device with a numeric keypad, and a 9" screen; Replicating the calculator interface in clickable buttons, with a textbox as simulated LCD is a horrible misuse of the potential of a computing environment. A screen, a keyboard and a hardware ALU. Being used to run an OS which draws some keys and a screen, interprets mouse movements, parses and interprets Applescript and p…

> It's almost funny, until you read his seven tenets of computing and find that any program which encounters any error should enter a debugger, so you can fix it and carry on. I think that would drive anyone insane.

You prefer inexplicable crashes? Now these are enough to drive someone mad.

And if you do prefer them, wire your debugger to a Blue Screen of Death emulation.

Re: Why Hypercard Had to Die

#115

Earlier quoted context omitted.

No, I said crash less . I completely avoid any debates about "perfect" software, they're pointless. Maybe I misunderstood you. When you said, "I think that would drive anyone insane", I assumed that for some reason we were talking about a greater quantity of crashes. (Might've been the "any program ... any error" bit beforehand.) Here, let's assume we're stuck with two options, and for both options, we'll assume that…

I was only mocking the author for wanting both ubiquitous debugging as a top-7 must have conputing feature, while at the same time decrying complexity and pining for a simple system. I agree with what you're saying, broadly.

> I was only mocking the author for wanting both ubiquitous debugging as a top-7 must have conputing feature, while at the same time decrying complexity and pining for a simple system.

There is no contradiction between the two:

http://en.wikipedia.org/wiki/Elektronika_BK

Re: Why Hypercard Had to Die

#116

I had a sudden hypothesis after reading this thread last night. (No proof, mind you, just an idea.) I wonder if HyperCard's success was for the same reason as UNIX's success: a well-chosen, small set of interoperable tools that allowed the user to do far more than the sum of their parts. And, as computing and interfaces have become more complex, we've just tacked on complexity to them rather than reinventing them to…

IMHO, the Linux programming environment is a mess precisely because not everything is a file handler - not even sockets, as even though sockets can behave like files, there are differences. Plan9 was supposed to be the reinvention of Unix and a lot of useful stuff was ported from Plan9 to modern-day Linux, including the /proc filesystem which is really, really useful.

Unfortunately the UNIX philosophy is so powerful that you don't understand it until you live and breathe UNIX. And it also doesn't scale for some use-cases, but this philosophy is the reason why UNIX is not only alive, but the dominant platform.

Also, HyperCard is NOT a "small set of interoperable tools". And neither is Excel.

Re: Why Hypercard Had to Die

#117
post #99

Earlier quoted context omitted.

And why does it need to be "deep"? It's good that it died because it doesn't "scale" to the elephantine size of software you're accustomed to?

> 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.

Steve Jobs demolished Apple and replaced it with Next.

Re: Why Hypercard Had to Die

#118

I loved Hypercard and BASIC too, but this post strikes me as being a little affected by nostalgia. With Hypercard you could make something for someone who 1) has an Apple, 2) Has Hypercard installed, and 3) Has the right version of Hypercard installed. With HTML/CSS/Javascript you can make something to run almost anywhere. It's not 'easy' but it is useful.

> With HTML/CSS/Javascript you can make something to run almost anywhere.

With gargantuan effort.

And your creation will still appear distorted in unpredictable ways to many users.

Re: Why Hypercard Had to Die

#119
post #97

I think what killed Hypercard, in some sense, was what it made popular: like the Amiga, it was too closely tied to its hardware. HyperCard ran black and white windows of 512*342 pixels because that is what the original Mac had (there was a version that did some color things, but that was and felt like a serious bolt-on job). Moreover, all graphics where bitmaps. Bringing that into the 'real world' as it existed at th…

I think that versions of Hypercard past v1.0 allowed for stacks of arbitrary window size; I know for a fact that I made up at least a few 1024x768 ones in v2.2.

You are correct in that I don't think it supported resizable windows without the use of some XCMD though.

Re: Why Hypercard Had to Die

#120
I remember using hyper studio (later version) in 5th grade in ~96. That was one of my earlier "programming" experiences and I spent a lot of time making a shooter called teddy bear doom for our class. However, the next year I found vb and found it a lot more flexible (I also decided I was a pc about that time)

The author makes an interesting point re: computers as bicycle vs train, that nothing like HyperCard exists today and apple now has a clear and hard separation between laying track and riding on it. I agree, but I wonder if HyperCard (or a modern version) makes the same mistake many wysiwyg solutions make: if you do something enough, you'll want more capable tools, and if you're a casual hobbyist, the wysiwyg solution will be too complicated anyway, with a disjointed interaction metaphor to boot. If I were a 5th grader today, I think I'd be better served by starting with python than something like hypercard.

Post reply on HN