And interestingly, given that's a Cyan game, their more famous title, Myst, was also just HyperCard stacks behind the scenes, with each world being it's own deck.
Strange article. It's an interesting and well-written piece relating what DNA wrote about Hypercard (and what Hypercard is), before suddenly switching to "educational models" without explanation, and then abruptly ending.
Haven't seen that format before. Substack ordinarily scatters various buttons/images/signups etc through an article so I'm accustomed to skipping over them to get to the next paragraph.
The subtitle of the article specifically mentions Educational Models, creating an expectation they will be covered as part of the subject matter. But then it's tacked on without any context or reason. Total non-sequitur.
It seems to me that something like this is really what the iPad is missing. Instead of each application being in its own sandbox, imagine if they were all scriptable, and the scripting language was as accessible as HyperCard was.
I’ve been using Shortcuts pretty extensively. There are challenges of course. But for the most part, it’s great. Most good apps expose their actions. The usual culprits like Outlook lock it down based on corporate policy. You can even make bespoke API calls. Siri is much more usable for me because of this.
There are major glaring issues - like the rigidness of the Timer and the lack of a separate “sleep” timer. No option to pause the shortcut for an extended period of time. And the all too familiar Apple bugs these days. In spite of all this it’s definitely one of the exciting things Apple has released - especially after they made it portable between the phone, watch, iPad, mac and HomePod - albeit limited.
I don't think AppleScript achieved anything like the approachability, discoverability, and delight of HyperCard. It wanted to appear similar, but was constantly stumbling over the wildly varying levels (and quality) of support found in different parts of the ecosystem.
On the side of developers writing apps to support AppleScript, it was a nightmare because the language was too flexible. I remember having to build parse trees to handle my DirectObjects and the various other English-language-sentence-diagram portions of an AppleEvent.
Does anyone know if there is a software that can open other software, manipulate that software, and then take the results of that manipulation and do other things with it?
I'm envisioning something like being able to tell the managing software to take your most recent photo, apply a filter to it, resize it with Waifu2x and then post it to your instagram or something similar.
Or to tell it to open Krita, make a line drawing of a character based on a photo, then use that as the input for stable diffusion 16 times and show me the results in a new folder.
I'm guessing the rudiments of such a system exist but that the control and orchestration element is missing.
The shortcuts app is a tantalizing glimpse of what could be. Directionally, it was a sea change for iOS when Apple acquired it and subsequently introduced its first-party iteration. But imagine the potential of Shortcuts if it were evolved into a fully-realized HyperCard successor.
BTW, for anyone into iOS and macOS automation, Jason Snell's use of Shortcuts is really interesting to read about: https://sixcolors.com/tag/automation/
> I had assumed that Apple would provide a way for Shortcuts to encode media into Apple Lossless format, but it doesn’t. The Encode Media action can encode audio, but only to M4A or AIF formats. Instead, I retreated to the command-line, since Apple provides a utility called afconvert that will let you convert audio files between an enormous number of formats, including not just Apple Lossless but the even more widely supported (and slightly more efficient) FLAC.https://sixcolors.com/post/2022/11/automate-this-audio-archi...
No reason each application can't have its own sandbox and be scriptable. Think of refs to other apps as a kind of capability. ToonTalk showed by example that a system along those lines could be usable and programmable by children.
Apparently his Mac was like an extension to Adams’ brain, and all of his work was stored on it. It might make it more brittle to changing technology, but on the other hand it was hugely productive for him.
The fact that Adams was the first European Mac owner and that Stephen Fry was the second warms my heart. If that was the only thing I remember from this article (very high probability), my day was still better from reading it.
> But Adams makes a powerful point: the general-purpose nature—as well as composability—of a piece of software is just as important as its low floors and its approachability.
This is an interesting take. From this perspective, I suppose Unix got composability right but its approachability to the average person is nearly zero.
In some way "pure" functional programming often feels the same way to me. Extremely composable but am I willing to trade approachability for that? And on second thought maybe that's true of "pure OO" languages too...
Maybe people feel the same way about hardcore text editors like vim or emacs?
The list goes on... I think I read somewhere that innovation is defined as the solution to a trade-off, and this particular battle between approachability and composability seems like a particularly fruitful avenue to explore if looking for "modern problems to solve"
I'd guess the Node.js and npm got composability w/ approachability formula the most correct. Rust comes close but using rust libraries is where approachability falls apart fast.
As for editors. Right now vscode get that formula the most correct.
As for Unix what do we have to compare it too? Everything more or less is a Unix these days. So it couldn't have got approachability that wrong.
I think the issue with npm is that it makes what should be a relatively important task (adding huge swathes of mostly unknown code) trivial to do, leading to all the bloat and abuse that ecosystem has seen. Sometimes a bit of friction that forces the user to slow down and truly understand what they're doing is a good thing...
The vulnerable part of the npm ecosystem is trust and end-user high-granularity control of trust.
If that problem can be solved, there's nothing inherently problematic with just using large swathes of mostly unknown code. Almost no Debian user knows the innards of every package they've installed, even the dev libraries they're building new applications on top of (to say nothing of every Ubuntu user).
(TBF to the ecosystem, there actually is a mechanism for flagging security issues in old library versions and surfacing those to a package builder. But it is up to the package builder to account for them by changing their dependencies).
I agree. To be more specific I think the problem with npm is that it explicitly trusts names and implicitly trusts their referents, which puts too heavy a burden on the name resolver.
Contrast this with apt, which inspects package signatures and compares them to keys I've trusted. If a package shows up with the same name as before, but different bits, and it's signed by somebody new, I have a reason to scrutinize it more heavily.
Npm does one thing particularly clever that a lot of other library / dependency infrastructures fail at: it supports multiple versions of the same library living in the codebase.
Because npm treats package dependencies recursively, a package depending on v1 of another package and a package depending on v2 of that package can actually live in the same codebase (with proper configuration; it comes as kind of a side-effect of transpilation and tree-shaking requiring the toolchain to rename symbols anyway, so the two different versions of the library just end up either properly hidden via module inclusion or in the same codebase but name-mangled to different things). This isn't foolproof (if one of those libraries leaks details of its dependency, and another piece of code tries to do `instanceof`, it's going to have a bad time), but it makes it easier to work with codebases one doesn't control.
"* From this perspective, I suppose Unix got composability right but its approachability to the average person is nearly zero.*"
I strongly agree with the first part of the sentence, but I disagree with the second. Considering the users that the Unix developers had in mind at the time---the late 1970s to late 1980s, say---its approachability was significantly better than the alternatives. (DCL, anyone?)
It wasn't until Unix expanded outside that niche that people began having bad reactions to it. :-)
Never played with the format back in the day, but while researching it a while back, I found that archive.org hosts some of the older ones & you can play with them online: https://archive.org/details/BeyondCyberpunkMacintosh
Reading this just makes me wonder if he ever (and surely he must have) used an Amiga. Why so bullish on the Macintosh with all its specific weirdness when, even as good as Apple was at the start did he not see the other more interesting forks in the ‘80s as worth it?
"It was an incredibly open-ended piece of software, allowing those without much expertise in programming (or even any at all) to build a wide variety of computational tools. To borrow a formulation from Seymour Papert (who co-created the programming language Logo), HyperCard had low floors and high ceilings."
Speaking as someone who used HyperCard to create a couple of applications, this is...somewhat overstated. It was quite good at creating things that resembled flipping through a deck of cards. (One app was a "smart test" that would present a more-or-less difficult question based on the user's previous answers---my first introduction to Bayesian statistics.)
It was, however, not a good programming environment if you needed to do anything complex---think of writing a complicated Emacs major mode, not using Emacs lisp but a simplified textual language intended for those without much expertise.
This is a general problem for systems built for "those without much expertise in programming (or even any at all)"; they may be able to do simple things, but you'll still need to be a "real programmer" to do slightly more complicated things, and a "real programmer" will be doing it with one hand tied behind their back.
As someone who also used Hypercard, I tend to agree. There's a reason we aren't still talking about Hypercard today the way it was talked about then, but it was a different time. We were so much more enamored with software's potential. Today, we get upset if a button press takes five seconds instead of one.
While I never used HyperCard, the ‘low floors and high ceilings’ makes me think of spreadsheets. Given that I code all day professionally, I have quite a high bar for using code to solve personal needs, but I love to use spreadsheets - there’s just enough automation to make powerful, useful mini-applications, quickly, without much complexity, and the presentation capabilities are very strong. While there is brittleness - I can share a budget sheet with my wife and it will be broken in minutes - it’s easy to fix and evolve, but most importantly, they are accessible and grokable for someone without much technical knowledge.
I guess spreadsheet apps are pretty self-contained so I’m not sure that composability is a strength.
I'm rather biased, but I think HyperTalk was mostly a mistake. A well-written HyperTalk script can be clear for a novice to read and (hopefully) modify, but this comes at the cost of making it an intensely longwinded, fiddly, and ambiguous language to program with and to implement. The focus on text manipulation as the primary "data handling" paradigm is very convenient for some problems, but the lack of proper lists and associative structures is a liability for complex programs.
Nevertheless, HyperCard on the whole was still enough to be highly empowering to a very broad userbase, which cannot be understated. It is difficult to quantify the amount of productivity and enjoyment that can be given to users simply by allowing them to make minor changes to personal software themselves, even if the bulk of the work was done by some "real programmer".
As someone who tried to use HyperCard and, after much lost time, went back to more traditional programming tools, I agree with your assessment. The idea behind HyperCard was neat, but HyperCard itself made it easy to write simple programs with lots of cute window dressing, and impossible to write complex ones.
> think of writing a complicated Emacs major mode, not using Emacs lisp but a simplified textual language intended for those without much expertise.
That's good enough to build form-based apps with basic conditional logic, which was Hypercard's biggest use case.
A person can sit through a Hypercard tutorial and learn how to build a small app using forms. That same person will have a much harder time rebuilding that app in PHP or Xamarin.
I think of HyperCard as sort of a domain-specific language for a certain UX.
If your application was naturally modeled as a set of records and where you wanted a nice UI to navigate and edit records, it was incredibly easy and productive to get up and running. It's hard to understate how much easier it was to make a GUI app for storing recipes or something along those lines in HyperCard compared to anything out there.
But, like other domain-specific languages, if your app didn't fit that UI style, it got real weird real fast and you felt like you were swimming upstream.
I used HC extensively, both by itself and with code resources that I wrote in Pascal or C. I certainly pushed it way beyond its capabilities, by using the parse-able pieces of text strings as crude data structures. What unreadable code I wrote. But HC was a great way to write small but useable programs for people.
I switched to Visual Basic when it came out. VB did a lot of what HC could do, plus it had more traditional structures, and was more than grudgingly supported.
> It was, however, not a good programming environment if you needed to do anything complex
I liked that they had an escape hatch, though. If you wanted to do complicated things and had the skill to do so, you could write an XCMD or XFCN in C or Pascal and which could be called from your Hypercard stack. Not a perfect system, but useful and extensible.
The seeming death of software that empowers users never ceases to make me sad. We have this machine of near limitless power and endless possibilities, and yet we do everything in our power to make doing things yourself esoteric. You have to pay someone to develop simple things you should absolutely be able to do yourself.
When I was a pre-teen my computer booted up to BASIC. I taught largely by guessing commands. I created many simple graphical games drawing lines and circles.
SCREEN 12
LINE 0 0 640 480 5
Imagine being a pre-teen today and just trying to draw a line to the screen. Several hundred lines of boilerplate. We've lost more than we've gained.
Totally agree. My grandfather was able to write entire applications in ~2000 lines of GWBasic without any external libraries. Achieving similar functionality today with a modern stack would be... pretty non-trivial.
Obviously BASIC isn't a super modern choice for a lot of reasons. But really makes you wonder. Modern development feels like needless abstraction spaghetti in comparison. It's all fluff driven by 'adoption', chained together with endless toolchains. Not that we haven't learned anything good in the last 30 years, but I think we could certainly stand to swing the pendulum back the other way a bit.
Alan Kay has a well-regarded talk called "Is it really 'Complex'? Or did we just make it 'Complicated'?". (Full disclosure, haven't seen it yet, but it sounds pretty topical)
https://www.youtube.com/watch?v=ubaX1Smg6pY
> My grandfather was able to write entire applications in ~2000 lines of GWBasic without any external libraries.
Yeah, I did that with my dad as a kid in the 1980s. Well, actually, they were polyglot apps using GWBASIC and DOS batch scripts, but…
If I had to rewrite them in modern Python or Ruby, using just the stdlib, they’d take far less code. (Now, if I was actually going to do it, I’d probably actually use some external libraries – if it was Python I’d use Click to give it a nice CLI and I’d probably at least bump it up to a TUI with Textual instead of leaving it straight line-oriented terminal style. But not because it wouldn’t be viable to do it without that, just because it would be worth the improvement.)
There's an online editor so pre-teens (or indeed post-teens) can get started right away (https://editor.p5js.org) but I'll admit there's still quite a hurdle if you want to host yourself, or run offline.
I keep trying to understand why Hypercard was good. Although I agree with the points in the article, I guess/think/suspect that there was more to it than that.
One of the things that struck me when I fired up Hypercard.sheepvm was that what came out of Hypercard is very different than what comes out of html/css/javascript. The same way that if you paint with a palette knife versus a paint brush, what comes out is different.
As a thought experiment, since I am currently building a website, I started using Hypercard to mock up the web UI. It is immediately different. (Yes I know there is the black&white vs colors). Does anyone have any thoughts on that or why that would be?
> I keep trying to understand why Hypercard was good.
I reckon it’s like the GUI version of BASIC.
It was, as other comments point out, kinda toy-like, but in a good way as well as a bad way.
It gave Mac users a way to “play” with their Mac and make it do their bidding in much the same way that BASIC interpreters built into pre-GUI home computers did.
It was half way between magic and godlike power - at least for some people. It gave a very low barrier to entry feeling of “Oh, I get it now. I can make this machine do what I want it to do. I am in control now!”
In my head, Director or Flash was the next equivalent tool in that niche.
If you love Douglas Adams, like I do, watch "Douglas Adams: Parrots, the Universe and Everything" [0], if you haven't done so. Heck, even if you did years ago.
65 comments
[ 2.3 ms ] story [ 116 ms ] threadAnd extended edition: https://youtu.be/5qxg0ykOcgM
The subtitle of the article specifically mentions Educational Models, creating an expectation they will be covered as part of the subject matter. But then it's tacked on without any context or reason. Total non-sequitur.
That would really be something.
There are major glaring issues - like the rigidness of the Timer and the lack of a separate “sleep” timer. No option to pause the shortcut for an extended period of time. And the all too familiar Apple bugs these days. In spite of all this it’s definitely one of the exciting things Apple has released - especially after they made it portable between the phone, watch, iPad, mac and HomePod - albeit limited.
On the side of developers writing apps to support AppleScript, it was a nightmare because the language was too flexible. I remember having to build parse trees to handle my DirectObjects and the various other English-language-sentence-diagram portions of an AppleEvent.
I'm envisioning something like being able to tell the managing software to take your most recent photo, apply a filter to it, resize it with Waifu2x and then post it to your instagram or something similar.
Or to tell it to open Krita, make a line drawing of a character based on a photo, then use that as the input for stable diffusion 16 times and show me the results in a new folder.
I'm guessing the rudiments of such a system exist but that the control and orchestration element is missing.
> I had assumed that Apple would provide a way for Shortcuts to encode media into Apple Lossless format, but it doesn’t. The Encode Media action can encode audio, but only to M4A or AIF formats. Instead, I retreated to the command-line, since Apple provides a utility called afconvert that will let you convert audio files between an enormous number of formats, including not just Apple Lossless but the even more widely supported (and slightly more efficient) FLAC. https://sixcolors.com/post/2022/11/automate-this-audio-archi...
https://youtu.be/1iAJPoc23-M
This is an interesting take. From this perspective, I suppose Unix got composability right but its approachability to the average person is nearly zero.
In some way "pure" functional programming often feels the same way to me. Extremely composable but am I willing to trade approachability for that? And on second thought maybe that's true of "pure OO" languages too...
Maybe people feel the same way about hardcore text editors like vim or emacs?
The list goes on... I think I read somewhere that innovation is defined as the solution to a trade-off, and this particular battle between approachability and composability seems like a particularly fruitful avenue to explore if looking for "modern problems to solve"
Or spreadsheets. Spreadsheets where the cells run little Python programs. Someone has done this I think, forget the name of the program…
As for editors. Right now vscode get that formula the most correct.
As for Unix what do we have to compare it too? Everything more or less is a Unix these days. So it couldn't have got approachability that wrong.
If that problem can be solved, there's nothing inherently problematic with just using large swathes of mostly unknown code. Almost no Debian user knows the innards of every package they've installed, even the dev libraries they're building new applications on top of (to say nothing of every Ubuntu user).
(TBF to the ecosystem, there actually is a mechanism for flagging security issues in old library versions and surfacing those to a package builder. But it is up to the package builder to account for them by changing their dependencies).
Contrast this with apt, which inspects package signatures and compares them to keys I've trusted. If a package shows up with the same name as before, but different bits, and it's signed by somebody new, I have a reason to scrutinize it more heavily.
Because npm treats package dependencies recursively, a package depending on v1 of another package and a package depending on v2 of that package can actually live in the same codebase (with proper configuration; it comes as kind of a side-effect of transpilation and tree-shaking requiring the toolchain to rename symbols anyway, so the two different versions of the library just end up either properly hidden via module inclusion or in the same codebase but name-mangled to different things). This isn't foolproof (if one of those libraries leaks details of its dependency, and another piece of code tries to do `instanceof`, it's going to have a bad time), but it makes it easier to work with codebases one doesn't control.
I strongly agree with the first part of the sentence, but I disagree with the second. Considering the users that the Unix developers had in mind at the time---the late 1970s to late 1980s, say---its approachability was significantly better than the alternatives. (DCL, anyone?)
It wasn't until Unix expanded outside that niche that people began having bad reactions to it. :-)
I always liked his take on Windows 95: https://www.info.ucl.ac.be/~pvr/os_hype.html
Speaking as someone who used HyperCard to create a couple of applications, this is...somewhat overstated. It was quite good at creating things that resembled flipping through a deck of cards. (One app was a "smart test" that would present a more-or-less difficult question based on the user's previous answers---my first introduction to Bayesian statistics.)
It was, however, not a good programming environment if you needed to do anything complex---think of writing a complicated Emacs major mode, not using Emacs lisp but a simplified textual language intended for those without much expertise.
This is a general problem for systems built for "those without much expertise in programming (or even any at all)"; they may be able to do simple things, but you'll still need to be a "real programmer" to do slightly more complicated things, and a "real programmer" will be doing it with one hand tied behind their back.
I guess spreadsheet apps are pretty self-contained so I’m not sure that composability is a strength.
Nevertheless, HyperCard on the whole was still enough to be highly empowering to a very broad userbase, which cannot be understated. It is difficult to quantify the amount of productivity and enjoyment that can be given to users simply by allowing them to make minor changes to personal software themselves, even if the bulk of the work was done by some "real programmer".
That's good enough to build form-based apps with basic conditional logic, which was Hypercard's biggest use case.
A person can sit through a Hypercard tutorial and learn how to build a small app using forms. That same person will have a much harder time rebuilding that app in PHP or Xamarin.
If your application was naturally modeled as a set of records and where you wanted a nice UI to navigate and edit records, it was incredibly easy and productive to get up and running. It's hard to understate how much easier it was to make a GUI app for storing recipes or something along those lines in HyperCard compared to anything out there.
But, like other domain-specific languages, if your app didn't fit that UI style, it got real weird real fast and you felt like you were swimming upstream.
I switched to Visual Basic when it came out. VB did a lot of what HC could do, plus it had more traditional structures, and was more than grudgingly supported.
I liked that they had an escape hatch, though. If you wanted to do complicated things and had the skill to do so, you could write an XCMD or XFCN in C or Pascal and which could be called from your Hypercard stack. Not a perfect system, but useful and extensible.
When I was a pre-teen my computer booted up to BASIC. I taught largely by guessing commands. I created many simple graphical games drawing lines and circles.
Imagine being a pre-teen today and just trying to draw a line to the screen. Several hundred lines of boilerplate. We've lost more than we've gained.Obviously BASIC isn't a super modern choice for a lot of reasons. But really makes you wonder. Modern development feels like needless abstraction spaghetti in comparison. It's all fluff driven by 'adoption', chained together with endless toolchains. Not that we haven't learned anything good in the last 30 years, but I think we could certainly stand to swing the pendulum back the other way a bit.
Alan Kay has a well-regarded talk called "Is it really 'Complex'? Or did we just make it 'Complicated'?". (Full disclosure, haven't seen it yet, but it sounds pretty topical) https://www.youtube.com/watch?v=ubaX1Smg6pY
Yeah, I did that with my dad as a kid in the 1980s. Well, actually, they were polyglot apps using GWBASIC and DOS batch scripts, but…
If I had to rewrite them in modern Python or Ruby, using just the stdlib, they’d take far less code. (Now, if I was actually going to do it, I’d probably actually use some external libraries – if it was Python I’d use Click to give it a nice CLI and I’d probably at least bump it up to a TUI with Textual instead of leaving it straight line-oriented terminal style. But not because it wouldn’t be viable to do it without that, just because it would be worth the improvement.)
One of the things that struck me when I fired up Hypercard.sheepvm was that what came out of Hypercard is very different than what comes out of html/css/javascript. The same way that if you paint with a palette knife versus a paint brush, what comes out is different.
As a thought experiment, since I am currently building a website, I started using Hypercard to mock up the web UI. It is immediately different. (Yes I know there is the black&white vs colors). Does anyone have any thoughts on that or why that would be?
I reckon it’s like the GUI version of BASIC.
It was, as other comments point out, kinda toy-like, but in a good way as well as a bad way.
It gave Mac users a way to “play” with their Mac and make it do their bidding in much the same way that BASIC interpreters built into pre-GUI home computers did.
It was half way between magic and godlike power - at least for some people. It gave a very low barrier to entry feeling of “Oh, I get it now. I can make this machine do what I want it to do. I am in control now!”
In my head, Director or Flash was the next equivalent tool in that niche.
There's a link to a browser version there too
[0]: https://www.youtube.com/watch?v=_ZG8HBuDjgc