5 ms·

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 BASI

by ezy 15y ago

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.

asciilifeform 15y ago
> This doesn't seem to be anything special about Hypercard. Tell that to the thousands of otherwise non-programming people who developed real, useful applications (some of them best-selling) in Hypercard. > it's going to be something else over the JS/CSS/HTML stack Like building a castle on a swamp. Foundations matter: http://www.loper-os.org/?p=55 http://www.loper-os.org/?p=55
- joe_the_user 15y ago
  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...
  - asciilifeform 15y ago
    So doing "it" right is a physical impossibility, then? Care to say why?
    - jodrellblank 15y ago
      Because 'right' is in the eye of the beholder? It's subjective.
      - loup-vaillant 15y ago
        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.
    - joe_the_user 15y ago
      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.
fleitz 15y ago
Nothing special, other than the fact that you could program a game like Myst in it.
- wvenable 15y ago
  You could program a game like Myst in almost anything -- even BASIC with line numbers. Edit: With the same amount of effort.
  - asciilifeform 15y ago
    Why not with a magnetized needle, too?
- masklinn 15y ago
  > other than the fact that you could program a game like Myst in it. As long as you knew C and could write the Hypercard extensions needed to make Myst actually work, of course.
flomo 15y ago
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.
- RexRollman 15y ago
  It's funny you mention a personal wiki. I think the first thing I used Hypercard for was to create a catalog of my comic book collection. (All of the work that went into it was lost due to an accident, which taught me a hard lesson about the need for backups.)
- ezy 15y ago
  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...
podperson 15y ago
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.

by ezy 15y ago

asciilifeform 15y ago

> This doesn't seem to be anything special about Hypercard. Tell that to the thousands of otherwise non-programming people who developed real, useful applications (some of them best-selling) in Hypercard. > it's going to be something else over the JS/CSS/HTML stack Like building a castle on a swamp. Foundations matter: http://www.loper-os.org/?p=55 http://www.loper-os.org/?p=55

joe_the_user 15y ago
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...
- asciilifeform 15y ago
  So doing "it" right is a physical impossibility, then? Care to say why?
  - jodrellblank 15y ago
    Because 'right' is in the eye of the beholder? It's subjective.
    - loup-vaillant 15y ago
      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.
  - joe_the_user 15y ago
    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.

fleitz 15y ago

Nothing special, other than the fact that you could program a game like Myst in it.

wvenable 15y ago
You could program a game like Myst in almost anything -- even BASIC with line numbers. Edit: With the same amount of effort.
- asciilifeform 15y ago
  Why not with a magnetized needle, too?
masklinn 15y ago
> other than the fact that you could program a game like Myst in it. As long as you knew C and could write the Hypercard extensions needed to make Myst actually work, of course.

flomo 15y ago

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.

RexRollman 15y ago
It's funny you mention a personal wiki. I think the first thing I used Hypercard for was to create a catalog of my comic book collection. (All of the work that went into it was lost due to an accident, which taught me a hard lesson about the need for backups.)
ezy 15y ago
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...

podperson 15y ago

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.