Live data from Hacker News

Why Hypercard Had to Die

loper-os.org

91–100 of 142 posts

Re: Why Hypercard Had to Die

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

Re: Why Hypercard Had to Die

#93
post #89

Earlier quoted context omitted.

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…

Have you never watched a video on your PC depute owning a perfectly serviceable TV?

Yes.

I have also loaded up an OS and browser built on a cross-platform GUI framework and a TCP-IP stack, and used it to do a DNS lookup and send a HTTP compliant request across a tangle of hundreds of miles of interconnected systems to Google's servers to statistically analyse my query, run it through around 700 servers, through an index of several billion web pages, and thousands of years of Youtube videos, millions of pictures, hundreds of thousands of news articles and twitter streams, ranking the results, and at the top putting the results of my calculation "2+1" or whatever.

But then, I'm not the author with the weirdo view of 'simple'. What's your point?

Re: Why Hypercard Had to Die

#95

There's no mystery, here. No great conspiracy -- the article has a screenshot of the smoking gun. http://www.loper-os.org/wp-content/hypercard-calc/hc12.jpg The scripting language had a verbosity and ambiguity that only a lawyer could love. The documentation for that language was similarly impenetrable to anyone with a background in CS, requiring a serious commitment to trial and error to perform operations that were…

It looks that way, but it is not that verbose. Compare:

    get name of me
    put the value of the last word of it after card field "lcd"
with

    it = event.target.name
    currentCard.fields["lcd"].append(it.text.asWords().last())
It looks verbose, and in some sense it is, but having lots of implicit state made it a nice environment for what it was.

Re: Why Hypercard Had to Die

#96

Earlier quoted context omitted.

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…

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 shop in just the last few days:

I don't need examples - I wrote my comment on a phone, and twice it popped up Input system error. The system is being restarted, which, it seems, is a spell-check problem. And that's a system which does me more annoyance than good even when it's working normally.

We have a firewall with a subsystem which crashes when enabled, and the manufacturer says it's a known problem with no estimated fix time, the only option is to disable that feature - one of their main selling points of the device.

A web server, showing problematic memory use and no process using it.

GVim on Windows 7 x64 - I could (not sure if I can remember what it was now) repeatedly make it hang, not just itself but also the entire OS, with an operation on a large file which is instant on Linux. Yet Task manager shows no high CPU or memory or disk use.

Anyway, it's like this for us all the time.

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?

You may as well ask a restaurant if you can watch the staff cook all your food over their shoulders so you can intercept and change things if you think it's going in a direction you don't want.

Even if you are able to taste too much sugar in an Apple Pie, it doesn't follow that you could remove the sugar if only you were in the kitchen watching how much was put in (it's dissolved by then), and it doesn't follow that you could tell if too much was put in just by looking - it depends on how sweet the apples are, and whether the sweetness changes with length of baking.

See also: the idea of systemantics.

And what am I going to do when it's your webserver crashing, or your iCloud server, or DropBox, or if it's my car navigation system or my phone's spell checker?

But, I would hope that that alone would motivate programmers to make them crash less.

Programmers don't make software that crashes for fun, you know. If it took no effort, they would make programs which don't crash right now. But it does take effort, and that's a limited resource which needs to be traded off.

Re: Why Hypercard Had to Die

#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 the end of the eighties would have taken a lot of resources, and it was not guaranteed that the end result would still be HyperCard. For example, if one allowed resizable windows, laymen would have to learn about layout algorithms ('is this button 50 pixels wide, or a quarter screen wide? Is it 20 pixels from the bottom, 10% of screen height, or should its bottom border match that of that text field over there?').

Also, at the time, there were attempts to include some Hypercard/Director-like features to QuickTime. HyperCard was considered for that functionality, but did not make the cut.

Re: Why Hypercard Had to Die

#98

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…

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

Well, that's our job. And, I specifically gave examples of unexpected behavior, in the sense that these were things that shouldn't ordinarily be behaving this way. The examples I gave were of cases where it definitely would help to have better troubleshooting tools available.

> And what am I going to do when it's your webserver crashing, or your iCloud server, or DropBox, or if it's my car navigation system or my phone's spell checker?

Whatever it is that you do now?

> Programmers don't make software that crashes for fun, you know.

I didn't say otherwise. Not sure why you brought this up.

I guess I still don't understand why "crash to debugger" would be worse than current behavior.

Re: Why Hypercard Had to Die

#99

Earlier quoted context omitted.

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…

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.

Re: Why Hypercard Had to Die

#100

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…

> Visual Basic 3?

Never used it, couldn't say. But, I did find some online tutorial type stuff for VB6: http://www.vb6.us/tutorials/little-more-advanced-hello-world...

I think we're going to get mired in semantics and splitting hairs. After all, "get name of me" doesn't objectively make any more sense than "lblHello.Caption". Still, I find HyperCard's interface much cleaner in general, and key phrases like "Private" and "Option Explicit" are to me huge red flags for a beginner language.

So, you're right that VB3 could be used for a "make a calculator" lesson in the first week of a programming class. But, so far, I think I'd rather do it in HyperCard.

Post reply on HN