Why Hypercard Had to Die (2011)(loper-os.org)
loper-os.org
Why Hypercard Had to Die (2011)
http://www.loper-os.org/?p=568
210 comments
Visual Basic. (The non-.NET versions)
And Delphi. Somehow all the RAD Programming Languages all died around the same time frame.
I still use it sometimes (and still supported in win10 believe it or not)!
And works really well on wine. The community is still quite active: http://planet-source-code.com/vb/default.asp?lngWId=1
There are options. Scratch comes to mind. Stacksmith is well on its way.
But what's to say it wouldn't have taken the course of HTML/CSS/JS if it ever got similarly popular?
I doubt it. When you made Hypercard stacks you did it in Hypercard. When you make websites, you make them in ... not a web browser.
Maybe I'm taking this too literally, but you can code Java in eclipse and web pages in several electron apps. What are you implying?
The parent is talking about an integrated environment for development, where that integrated environment is indistinguishable from the language itself.
Examples of this include elisp and emacs, smalltalk and squeak, and to a lesser extent visual studio and C#.
There have been relatively few ecosystems so integrated. Java and Javascript/html/electron apps are notably not like that at all. There is no one "the" environment for coding those, simply several very popular ones.
Examples of this include elisp and emacs, smalltalk and squeak, and to a lesser extent visual studio and C#.
There have been relatively few ecosystems so integrated. Java and Javascript/html/electron apps are notably not like that at all. There is no one "the" environment for coding those, simply several very popular ones.
Yes exactly.
My own take is that Apple should have made a "Hypercard"-like thing the "top layer" of a new operating system. In other words, the entire desktop/windows/buttons interface to the main OS would be itself scripted in Hypercard.
Smalltalk takes this a step further of course by making the whole operating system a live environment. The very UI vocabulary one uses can also double as "programming"
My own take is that Apple should have made a "Hypercard"-like thing the "top layer" of a new operating system. In other words, the entire desktop/windows/buttons interface to the main OS would be itself scripted in Hypercard.
Smalltalk takes this a step further of course by making the whole operating system a live environment. The very UI vocabulary one uses can also double as "programming"
That was the idea behind AppleScript to an extent.
Hmm. Unity scripting sort of works like this if you if ignore the closed source parts. It's kind of nice to edit the editor.
At the same time, having the power to corrupt your runtime is arguably more trouble than it's worth.
It is closer to the ideals of smalltalk and LISP (of the '70s) - where there is little or no distinction between the environment in which one writes the software and the environment that the software is run.
This is a fundamentally different way of how the environment works. You could stop a program and access the development environment because that was part of the runtime.
This is a fundamentally different way of how the environment works. You could stop a program and access the development environment because that was part of the runtime.
Except you did make websites in a web browser originally.
https://en.wikipedia.org/wiki/WorldWideWeb
Netscape was going to have a built in editor, but they ran out of time, was added in Netscape 3 Gold, and there by default in 4.
https://en.wikipedia.org/wiki/WorldWideWeb
Netscape was going to have a built in editor, but they ran out of time, was added in Netscape 3 Gold, and there by default in 4.
Also, modern Dev Tools in all the major browsers are getting close to being full blown IDEs in their own right (again). It's got a full REPL one F12 (or Ctrl+Shift+I) press away. (Plus modern syntax highlighting, element inspection, direct CSS and sometimes JS file modification.)
(Pre-Edgmium, Edge's Dev Tools even shared a bunch of code with VS Code and briefly explored hosting a full VS Code experience.)
(Pre-Edgmium, Edge's Dev Tools even shared a bunch of code with VS Code and briefly explored hosting a full VS Code experience.)
$ seamonkey-bin --edit
::ye olde Mozilla Composer appears directly::
No you wouldn't, but you can ;) How high is your tolerance today?
::ye olde Mozilla Composer appears directly::
No you wouldn't, but you can ;) How high is your tolerance today?
I would, why wouldn't i? If all you need is to write some formatted text with a bunch of images and perhaps a table or two, composer does the job perfectly fine and the page you get works on any server and client with practically zero overhead and resources.
They wouldn't. You would, that's fine, and I made a site with it in the distant past, or I tried. I checked, but if I did actually publish it, archive.org doesn't have that version.
I say tolerance because much more recently I had problems trying to make a chart and tripping over colspan and rowspan stuff. I really just need to sketch the contents out on paper, first...
I say tolerance because much more recently I had problems trying to make a chart and tripping over colspan and rowspan stuff. I really just need to sketch the contents out on paper, first...
I'm not sure i understand, your issue with Composer was making a chart? Why would you try to make a chart in Composer, it is a page editor not an image editor, why not make the chart in a tool made specifically for charts and use it as an image? Also what tables and colspan/rowspan have to do with charts?
Sorry, I meant table and started saying so but I cut that part out at some point. I also tried lowriter; editing tables and rows and cells is better, but not by much.
Hey, Netscape Composer's how I got my start on this boring but too-lucrative-to-give-up road. I definitely made websites in my browser :-)
It was really a thing that could, theoretically, have taken the course of Director or Flash. You can imagine a parallel universe where that happened and my guess is the final result would have been the same.
CSS has one of the strangest designs in all of computing. It's simultaneously Turing-complete yet too weak to easily encode many common types of styling. It has practically no abstraction capabilities, no namespacing, and its syntax at every level (selector syntax, Unicode escaping, etc) is different from the other languages it has to interoperate with, for no apparent reason.
I doubt Hypercard would have ever gotten anything like CSS. It was unlikely enough that CSS ended up anything like CSS!
I doubt Hypercard would have ever gotten anything like CSS. It was unlikely enough that CSS ended up anything like CSS!
Then it sounds like there's money to be made then. I've never used hypercard, but perhaps it could fill a similar niche as wix?
I've never used Hypercard and I just can't fathom the love for it.
If nothing matches Hypercard, why don't people use it (or some opensource copy) of it? So many seem enthralled by it but the reality is no one seems to want to bring it back.
If nothing matches Hypercard, why don't people use it (or some opensource copy) of it? So many seem enthralled by it but the reality is no one seems to want to bring it back.
They do, it's just fragmented. Things like Excel/VB, Quickbase, Airtable, Tableux, etc.
Because newer copies don’t include the nostalgia that’s one of the primary drivers for people’s admiration.
Well, the main reason no one uses Hypercard itself is because emulating classic MacOS is a pain and a half.
I haven't explored all the copies, but the ones I have seen tend to be less featureful and/or less user-friendly than the original.
Furthermore, probably the best modern software that's similar to Hypercard in its overall flexibility and power is...the web. Back in the day, Hypercard was it; there wasn't really anything else in that space. Nowadays, there's still nothing that's quite as awesome or matches all its features, but there are things that are much closer and do a lot of the same things that are much more accessible than emulating or reimplementing Hypercard.
I haven't explored all the copies, but the ones I have seen tend to be less featureful and/or less user-friendly than the original.
Furthermore, probably the best modern software that's similar to Hypercard in its overall flexibility and power is...the web. Back in the day, Hypercard was it; there wasn't really anything else in that space. Nowadays, there's still nothing that's quite as awesome or matches all its features, but there are things that are much closer and do a lot of the same things that are much more accessible than emulating or reimplementing Hypercard.
Emulating Mac OS classic isn't particularly difficult these days. I use sheepshaver with great success. I actually DO use it to run my old hypercard games I wrote in elementary school.
Last time I tried using Basilisk II, I managed to get it to be stable (running System 7 in an emulated...IIsi, I think?), but if I ever tried to change anything beyond adding and removing disks, it just wouldn't run.
I haven't tried SheepShaver much, I admit, because most of the stuff I want to run was written for 68k and runs poorly or not at all on PPC.
I haven't tried SheepShaver much, I admit, because most of the stuff I want to run was written for 68k and runs poorly or not at all on PPC.
The existence of the Web is indeed a big reason. While everybody seems to compare Hypercard to things like Visual Basic, and yes, you could use it that way to make applications, most people used it to create stacks on a topic (a particular band, or Shakespeare's plays, or Japanese swords) that were basically Web sites before the Web.
LiveCode (renamed from "Runtime Revolution"). Free for personal use: https://livecode.com/products/community-edition/.
I guess DreamWeaver might be the modern equivalent (though definitely not as easy to use as Hypercard). Can DreamWeaver set up client-side storage easily? With Hypercard it was dead simple to save stuff to local storage.
Project I am working on that may be close: https://diasli.de
Looks nice! But why is it in dutch? Does it load language settings based on location? Why can't I change it?
It selects the language based on browser locale - what is yours set to? Should definitively improve this...
From Dutch you can switch to English using the menu in the top right corner (click "Engels")
From Dutch you can switch to English using the menu in the top right corner (click "Engels")
Great, thanks! I checked the menu but probably missed the language settings.
Its power was partly in its ubiquity - people who weren't programmers stumbled across it, had a play and suddenly realised 'this is a bit handy'. There was never really a killer app for Hypercard, it had so many bizarre use-case cases. But its flexibility and ability welcome unlikely users in is where it did so well.
I might consider Myst a “killer app,” especially for its time.
It was a different time, the world moved on to web enabled / multi-user applications. Hypercard and MS Access where decidedly built around single users with the latter having multi-user capabilities but not great support for it. They where both designed in a time where a constant network connection was a luxury and not a commodity. They where awesome for their time, but it was also a simpler time, as of yet no one has come up with a stupid simple app builder for present day computing realities as complexity has exploded, its a interesting problem and if a person could make creating simple apps for web/mobile/multi-user as easy as Hypercard was, they would certainly be rolling in fortunes.
One of the attractions of Hypercard was that a "stack" (document) was entirely self-contained; and would always behave exactly the same on any machine where HC could run.
Notably, would run without any need for servers (or, worse, the subscription-and-lock-in "services" ubiquitous today -- arguably the 1980s "computer revolution" was strangled in the cradle, and we've gone most of the way back to 1970s-style time-sharing now: how many phone apps etc. will run usefully without a net connection? The "smartphone" is essentially a small "glass TTY", rather than personal computer in the '80s sense.)
I've run HC stacks written 30+ years ago. How many current-day "web app" documents will be readable as-found 30 years from now? For that matter, I've paid for iOS apps that would no longer execute after half a year (on account of Apple's "API changes", or in some cases -- author's "call home" server fell down and did not get up, etc.) Permanence (in the most basic "I paid for this and it ought to be usable for so long as any compatible iron remains functional" sense) is no longer part of the software commercial culture, and one is likely to be laughed at for merely raising the question.
Notably, would run without any need for servers (or, worse, the subscription-and-lock-in "services" ubiquitous today -- arguably the 1980s "computer revolution" was strangled in the cradle, and we've gone most of the way back to 1970s-style time-sharing now: how many phone apps etc. will run usefully without a net connection? The "smartphone" is essentially a small "glass TTY", rather than personal computer in the '80s sense.)
I've run HC stacks written 30+ years ago. How many current-day "web app" documents will be readable as-found 30 years from now? For that matter, I've paid for iOS apps that would no longer execute after half a year (on account of Apple's "API changes", or in some cases -- author's "call home" server fell down and did not get up, etc.) Permanence (in the most basic "I paid for this and it ought to be usable for so long as any compatible iron remains functional" sense) is no longer part of the software commercial culture, and one is likely to be laughed at for merely raising the question.
> The "smartphone" is essentially a small "glass TTY", rather than personal computer in the '80s sense.
We now have a generation or two that completely missed this era, and, worse, might be uninterested in the history. The idea that you would have a ubiquitous, portable, always-on personal computing device and that -- at least from the perspective of people who are knowledgeable of about this history -- you would put a Unix on it is completely crazy.
It is, as you say, an expensive and sleek teletype emulator
We now have a generation or two that completely missed this era, and, worse, might be uninterested in the history. The idea that you would have a ubiquitous, portable, always-on personal computing device and that -- at least from the perspective of people who are knowledgeable of about this history -- you would put a Unix on it is completely crazy.
It is, as you say, an expensive and sleek teletype emulator
I would argue that Visual Basic on Windows was similar to HyperCard for Mac!
It also led to a great number of “regular folks” making “forms” and adding code. And VBX allowed people in Excel to do stuff.
Also don’t forget AppleScript. And now on iOS we have Shortcuts and Workflow too.
It also led to a great number of “regular folks” making “forms” and adding code. And VBX allowed people in Excel to do stuff.
Also don’t forget AppleScript. And now on iOS we have Shortcuts and Workflow too.
HTML/Javascript get pretty close. Apples to Studebakers comparison, not withstanding.
you might want to check https://www.livecode.com is is a modern day xtalk, it uses a language and model just like HyperCard but it creates standalones for windows, mac, linux, android and iOS.
PS: Disclaimer, I work for them.
PS: Disclaimer, I work for them.
i poked around the website and forum a bit and one thing I missed was a way to see community libraries and projects. check out the euphoria site for instance: http://rapideuphoria.com/archive.htm
I totally agree with you that the site needs more work to make these things more discoverable. We don't have a package manager (I built one more than ten years ago, it never got traction and it was very naive) but there are many libraries floating around. Our forums and mailing lists are the most common places to find resources. The IDE also has an online portal inside it that can be used to share code, most people use it to share demos, samples and libraries.
yeah, that's why i feel like euphoria is a good example - they have a small (but, from what i can see, enthusiastic) community, and their website doesn't have a ton of polish, but it's pretty pleasant to navigate and makes things very discoverable.
Watch Notion. It's not there yet, but as the API develops it could easily be the next Hypercard.
Notion as in [1] ? I thought Coda [2] would be closer ?
[1] https://www.notion.so
[2] https://coda.io/welcome
[1] https://www.notion.so
[2] https://coda.io/welcome
> At the bottom of the comments, a member of the Hypercard team said it was killed in 92, before Jobs returned.
Well, HyperCard had several lives.
An early version of HyperCard 3.0 was demonstrated at WWDC in 1996 which used QuickTime ("QuickTime Interactive", or QTi) as its runtime. That would've allowed stacks to run in browsers, and in every app that leveraged QuickTime to render multimedia content.
The 1992 killing was before my time, but in any case HyperCard was effectively killed forever in 2000 when Jobs reassigned the HyperCard engineering team to not-HyperCard.
Well, HyperCard had several lives.
An early version of HyperCard 3.0 was demonstrated at WWDC in 1996 which used QuickTime ("QuickTime Interactive", or QTi) as its runtime. That would've allowed stacks to run in browsers, and in every app that leveraged QuickTime to render multimedia content.
The 1992 killing was before my time, but in any case HyperCard was effectively killed forever in 2000 when Jobs reassigned the HyperCard engineering team to not-HyperCard.
Author of linked piece speaking. Seems like many readers continue to miss the essential point, just as they did in 2011:
Hypercard wasn't a gem of graphic design (1-bit colour, plain line graphics) or of programming language design (one of the many laughable attempts at "natural language programming") or of high-performance number crunching... but it was simple. I.e., the entire system was fully covered by ~100 pages of printed manual. It fit in one's head. (And did not take 20 years to fit-in-head, either, an intelligent child could become "master of all he surveys" in a week or two.)
Where is the printed manual for the current MS VB, or the WWW's HTML/JS/CSS/etc stack (yes including all browser warts), or for any of the other proposed "replacements" ? How many trees would have to be killed to print such a manual, and would it fit in your house? Could you read it cover to cover, or would die of old age first?
Hypercard wasn't a gem of graphic design (1-bit colour, plain line graphics) or of programming language design (one of the many laughable attempts at "natural language programming") or of high-performance number crunching... but it was simple. I.e., the entire system was fully covered by ~100 pages of printed manual. It fit in one's head. (And did not take 20 years to fit-in-head, either, an intelligent child could become "master of all he surveys" in a week or two.)
Where is the printed manual for the current MS VB, or the WWW's HTML/JS/CSS/etc stack (yes including all browser warts), or for any of the other proposed "replacements" ? How many trees would have to be killed to print such a manual, and would it fit in your house? Could you read it cover to cover, or would die of old age first?
Do I recognize your name and writing style from Kuro5hin?
Doubt it: I have not written at Kuro5hin. (Possibly linked there at some point, however?)
When Hypercard was new, you could use it to create user interfaces that looked and felt exactly like all the other Macintosh applications of the era- within a reasonable margin, anyway.
Basic expectations are now higher. UIs are more visually complex and subtle. You can't just freehand them with a rectangle tool and a few canned textures. UIs are expected to reflow to devices with different screen sizes and dot pitches. Users expect their programs to give them up-to-the-minute information from the internet, with slick animation and nuanced typography. With flexibility comes inescapable complexity.
Could you make a tool as easy to use as Hypercard, and let modern users create useful applications for themselves? Sure, but the results wouldn't be nearly as nice as the applications built with conventional tools that live alongside them. I have a tremendous fondness for Hypercard, but I don't think you could ever make something today which was empowering and full-featured like Hypercard was for its day.
Basic expectations are now higher. UIs are more visually complex and subtle. You can't just freehand them with a rectangle tool and a few canned textures. UIs are expected to reflow to devices with different screen sizes and dot pitches. Users expect their programs to give them up-to-the-minute information from the internet, with slick animation and nuanced typography. With flexibility comes inescapable complexity.
Could you make a tool as easy to use as Hypercard, and let modern users create useful applications for themselves? Sure, but the results wouldn't be nearly as nice as the applications built with conventional tools that live alongside them. I have a tremendous fondness for Hypercard, but I don't think you could ever make something today which was empowering and full-featured like Hypercard was for its day.
You can't just freehand them with a rectangle tool and a few canned textures.
I mean, why not? If I'm a small business, and I need a custom (in-house) app, AND I could do it myself with little training, I'd rather do that then not have the business. (Again) how many businesses run on Excel Spreadsheets? Not every business can hire a programming firm to make a boutique app that's used by 100 people.
But I'm also one of those, "Why did FileMaker Pro die?" kinda person. And I still write Perl. I'm a weirdo, but I'm a pragmatic weirdo that likes to get stuff done.
I mean, why not? If I'm a small business, and I need a custom (in-house) app, AND I could do it myself with little training, I'd rather do that then not have the business. (Again) how many businesses run on Excel Spreadsheets? Not every business can hire a programming firm to make a boutique app that's used by 100 people.
But I'm also one of those, "Why did FileMaker Pro die?" kinda person. And I still write Perl. I'm a weirdo, but I'm a pragmatic weirdo that likes to get stuff done.
I do a lot of freelance and I can't tell you how many businesses I've worked with who had some need that was just a smidge more than their current software would allow. If there was something in between using an interface and learning a full-fledged programming stack from first principles, it would go a long way.
Part of this goes towards getting people -- both today's mainstream developers and users -- to think hard about what using a personal computer should mean.
I can't think of a better definition of programming than "telling a computer what to do." That should be the first hint.
Part of this goes towards getting people -- both today's mainstream developers and users -- to think hard about what using a personal computer should mean.
I can't think of a better definition of programming than "telling a computer what to do." That should be the first hint.
This came up the other day in a different thread but I think it bears repeating. I am generally an Electron hater, but there’s this huge opportunity for applications to provide access to a JS REPL inside Electron apps to give users the ability to tweak apps to fit their needs. Not just a “we’ve included scripting functionality” like eg VBA gives you, but access to the whole damned thing!
I can dream anyway.
I can dream anyway.
That's part of the reason why Emacs has this kind of cult following. There's always something you need that's "just a smidge more" than your Emacs can do, but it's very easy to just code up that missing bit. It might be not for casual user (requires learning some basics of programming), but then again, the legend goes that secretaries used to use Emacs and like it, for similar reasons people like Excel today - they need something extra, they can make it themselves on the spot.
And another thing people should learn from that, never underestimate secretaries, accountants etc.
It is often good to limit what non admins can do to the system, servers, their computer os etc.
We should also limit who has access to sensitive data.
But I think often companies could be more productive if they taught their employees to script a bit.
It is often good to limit what non admins can do to the system, servers, their computer os etc.
We should also limit who has access to sensitive data.
But I think often companies could be more productive if they taught their employees to script a bit.
> And another thing people should learn from that, never underestimate secretaries, accountants etc.
It is difficult for the modern developer to think of users as anything other than dumb cattle, because doing so would raise ethical concerns about their high-engagement eyeball-farming products.
It is difficult for the modern developer to think of users as anything other than dumb cattle, because doing so would raise ethical concerns about their high-engagement eyeball-farming products.
Back with Multics, secretaries were given Emacs as editor, and they had access to a manual on writing lisp code for it... With no mention anywhere that it was programming in one of the most capable languages of the time (MACLISP on Multics).
In short time, many secretaries that honestly believed that "programming wasn't for them and was too hard" had written lots and lots of automation for their daily tasks. Cava was their Hypercard.
http://www.gnu.org/gnu/rms-lisp.en.html
In short time, many secretaries that honestly believed that "programming wasn't for them and was too hard" had written lots and lots of automation for their daily tasks. Cava was their Hypercard.
http://www.gnu.org/gnu/rms-lisp.en.html
I've been working on something like this, a visual programming language called BlockStudio [1]
1. www.blockstud.io
>Why did FileMaker Pro die?
Did it, really? I still find it amazing. I did wonders with the lightweight version of it that came with Claris/Apple Works
Did it, really? I still find it amazing. I did wonders with the lightweight version of it that came with Claris/Apple Works
> Why did FileMaker die?
IDK, but 80% of web apps were during the 2000s so so interfaces on top of a relational database...
And FileMaker was so superior...
Seems that in computer we try end to think that "worst is better".
IDK, but 80% of web apps were during the 2000s so so interfaces on top of a relational database...
And FileMaker was so superior...
Seems that in computer we try end to think that "worst is better".
In 2010s they still were, but with "relational database" part swapped out for something worse still.
If you squint, you can just see many webapps as taking what would work better as a bunch of MS Access forms, and locking it down from every possible side so that there's a directed flow users can't deviate from, and so that they can't possibly do anything with their data that the webapp owners don't allow.
If you squint, you can just see many webapps as taking what would work better as a bunch of MS Access forms, and locking it down from every possible side so that there's a directed flow users can't deviate from, and so that they can't possibly do anything with their data that the webapp owners don't allow.
FileMaker Pro is still around.
With new versions that they email me about every couple of days.
> But I'm also one of those, "Why did FileMaker Pro die?" kinda person.
FileMaker is not dead[1], and in fact it's now a highly-rated "Low-Code Platform For Business Developers".[2]
[1] https://www.filemaker.com/ [2] https://content.filemaker.com/2019_FM_forrester_report
FileMaker is not dead[1], and in fact it's now a highly-rated "Low-Code Platform For Business Developers".[2]
[1] https://www.filemaker.com/ [2] https://content.filemaker.com/2019_FM_forrester_report
>I mean, why not? If I'm a small business, and I need a custom (in-house) app, AND I could do it myself with little training, I'd rather do that then not have the business.
The first company I worked for developed such a system and it worked out very well for them. You would write your UI in XML and your business logic as Postgres stored procedures using either PLPGSQL or any number of other languages with Postgres bindings. They then had a C frontend which would parse the XML and render out the UI using either GTK or HTML. It also had the ability to make arbitrary HTTP requests which allowed for some pretty sophisticated integrations.
Everything about this felt wrong yet it allowed the company to rapidly deliver new functionality and bespoke customizations, on site and often in a matter of hours. It was also simple to the point they could train others in the business (outside of development) to use it.
The first company I worked for developed such a system and it worked out very well for them. You would write your UI in XML and your business logic as Postgres stored procedures using either PLPGSQL or any number of other languages with Postgres bindings. They then had a C frontend which would parse the XML and render out the UI using either GTK or HTML. It also had the ability to make arbitrary HTTP requests which allowed for some pretty sophisticated integrations.
Everything about this felt wrong yet it allowed the company to rapidly deliver new functionality and bespoke customizations, on site and often in a matter of hours. It was also simple to the point they could train others in the business (outside of development) to use it.
FileMaker Pro is pretty much alive, they have a conference happening in two weeks: https://www.filemaker.com/learning/devcon/
There are many companies using it.
There are many companies using it.
Hypercard seems rather reminiscent of VisualBasic to me, so I can understand its popularity. The difference seems that Microsoft embraced its quirks and shifted it into several areas (VBA for the office product, and perhaps VBScript for IE). VB became vb.net which was succeeded by c#, as the language (vb/c# and others) became decoupled from the development environment.
The main modern difference between ye-olde hypercard and vb, is that the whole ecosystem was a monolith, whereas now it's disconnected.
The main modern difference between ye-olde hypercard and vb, is that the whole ecosystem was a monolith, whereas now it's disconnected.
>Hypercard seems rather reminiscent of VisualBasic…
Hypercard predates VisualBasic by many years
Hypercard predates VisualBasic by many years
Great correction, thanks!
I actually meant that it reminded me of ye olde-VB (because it's ancient in its own right).
I would say it was closer to access and access forms than to VB. It was more UI centric where you just added snippets of scripts for button clicks and other actions. Access forms where like this but had wiring to the Access Database that was the real difference between the two. Hypercard was UI focused and access was data focused but both had the concept of layout the form and add snippets of glue. I would put Macromedia Director in this class of applications as well.
"Users expect their programs to give them up-to-the-minute information from the internet, with slick animation and nuanced typography." This is what is the problem. It is also why I often write my own, because, I do not want those features.
Rather, better features can include such as keyboard commands (including prefixes, etc), compact view that still includes the relevant information, mouse chording, programmability (for data-oriented stuff, the ability to run SQL queries can help), etc
Rather, better features can include such as keyboard commands (including prefixes, etc), compact view that still includes the relevant information, mouse chording, programmability (for data-oriented stuff, the ability to run SQL queries can help), etc
When Hypercard was new, you could use it to create user interfaces that looked and felt exactly like all the other Macintosh applications of the era
Maybe someone could, if they put a lot of effort into it but I think you're misremembering this. Typical Hypercard stacks felt like Hypercard stacks and not other Mac apps. There were lots of nonstandard buttons and icons, no pop up menus, the menu bar wasn't used, etc. UI triggered by mouseover was easy and common in Hypercard, not so much in standard Mac apps.
Maybe someone could, if they put a lot of effort into it but I think you're misremembering this. Typical Hypercard stacks felt like Hypercard stacks and not other Mac apps. There were lots of nonstandard buttons and icons, no pop up menus, the menu bar wasn't used, etc. UI triggered by mouseover was easy and common in Hypercard, not so much in standard Mac apps.
Maybe , just maybe HyperCard wasn't meant for professionals to make and sell programmers. Maybe if people had something like HyperCard today, they wouldn't need us programmers.
You shouldn't have been downvoted, as you're spot on.
Programmers who feel hurt, please take in mind that there will always be the need for system programming and building software platforms for enterprise levels; but the vast majority of small "business workflow" use cases would be best served by a tool allowing the final user to explore their needs and build a small interface to process .
Compare it to needing to call a interior designer or handyman to hang every picture in your home. You only should need hire professional contractors for real work, but small changes should be within the reach of laymen with simple tools.
Programmers who feel hurt, please take in mind that there will always be the need for system programming and building software platforms for enterprise levels; but the vast majority of small "business workflow" use cases would be best served by a tool allowing the final user to explore their needs and build a small interface to process .
Compare it to needing to call a interior designer or handyman to hang every picture in your home. You only should need hire professional contractors for real work, but small changes should be within the reach of laymen with simple tools.
Isn't that kind of what Lotus Notes did? Everyone ended up hating the email client foisted on people after IBM bought it, but the workflow capabilities and and form designer were really nice.
Yes; unfortunately the culture of "do it yourself software" died when Apple's model of "information appliance" took off.[1]
[1] See related article by same author: http://www.loper-os.org/?p=316 On the Still-Undefeated Tyranny of Apple.
[1] See related article by same author: http://www.loper-os.org/?p=316 On the Still-Undefeated Tyranny of Apple.
> UIs are expected to reflow to devices with different screen sizes and dot pitches
> Users expect their programs to give them up-to-the-minute information from the internet, with slick animation and nuanced typography.
Do these requirements really come from the users? Or do they, in fact, come mainly from tech people? I never understood this mentality that mobile devices must be considered at all costs for all cases, and it seems to me that this mentality comes and always came from industry people, not users. I suspect this is related to three things:
- The laptop/PC market is "saturated", in the sense that it can no longer hyper-grow, so it's not so convenient to make a billion or two;
- A new zoo of careers paths has grown out of mobile and the startup era: UX designer, Product-Whatever, Growth-"Hacker", Agile Wizard, Evangelist Something etc, etc. It's very hard to convince someone of something when they salary depends on them not believing it, says the cliché but is true;
- It is more lucrative to show ads to passive consumers than to sell software to creators.*
This is a situation where the current game of Silicon Valley capitalism (copied everywhere) configures a race to the bottom in terms of the expression of human potential.
* This is why, even when you want to buy a tool, you now have to "subscribe to a service", with the loss of sense of ownership and control that comes with it.
> Users expect their programs to give them up-to-the-minute information from the internet, with slick animation and nuanced typography.
Do these requirements really come from the users? Or do they, in fact, come mainly from tech people? I never understood this mentality that mobile devices must be considered at all costs for all cases, and it seems to me that this mentality comes and always came from industry people, not users. I suspect this is related to three things:
- The laptop/PC market is "saturated", in the sense that it can no longer hyper-grow, so it's not so convenient to make a billion or two;
- A new zoo of careers paths has grown out of mobile and the startup era: UX designer, Product-Whatever, Growth-"Hacker", Agile Wizard, Evangelist Something etc, etc. It's very hard to convince someone of something when they salary depends on them not believing it, says the cliché but is true;
- It is more lucrative to show ads to passive consumers than to sell software to creators.*
This is a situation where the current game of Silicon Valley capitalism (copied everywhere) configures a race to the bottom in terms of the expression of human potential.
* This is why, even when you want to buy a tool, you now have to "subscribe to a service", with the loss of sense of ownership and control that comes with it.
> Do these requirements really come from the users? Or do they, in fact, come mainly from tech people?
I think a lot of them come from the "expectations" about computing created by the world of web applications. And those requirements themselves come from, most importantly, the advertising industry. In one way or another, by varying but important degrees, advertising defines how we create these interactive systems and worsens the user/developer divide
I think a lot of them come from the "expectations" about computing created by the world of web applications. And those requirements themselves come from, most importantly, the advertising industry. In one way or another, by varying but important degrees, advertising defines how we create these interactive systems and worsens the user/developer divide
The standard Hypercard should be compared against is janky, macro laden excel based “tools.”
Users don’t have these basic expectations you’re talking about of internal software. Every large company I’ve ever worked for or with has tons of critical business processes that are 100% dependent on some shitty spreadsheet that gets passed around.
Users don’t have these basic expectations you’re talking about of internal software. Every large company I’ve ever worked for or with has tons of critical business processes that are 100% dependent on some shitty spreadsheet that gets passed around.
> Users expect their programs to give them up-to-the-minute information from the internet, with slick animation and nuanced typography.
Did you ever watch an average Joe, who has zero understanding what involves programming a computer actually use a computer?
Let me let you in on a secret: The average user doesn't care!
The average user doesn't care how fancy or not a UI looks like, if it follows the interface guidelines. The average user doesn't care if a UI is responsive. The average user doesn't care about smooth animations. The average user doesn't care about slick typography (they prefer horrible Word-Art, Comic Sans and Papyrus). The average user doesn't even care about up-to-the-minute information!
It is developers and people who have an understanding of the problems that must be solved to provide slick animations, responsive UIs, good typography and continuous data updates. Most developers, when thinking about a user think about themselves when they use someone else's product.
My mother already goes off the rails, if an update on her computer just updates one minor detail in the UI toolkits styling. Or if an iconset updates a previously inconsistent or missing icon.
Users care about consistency! It doesn't matter how bad a program is done in a certain aspect, as long it is and stays consistent.
Did you ever watch an average Joe, who has zero understanding what involves programming a computer actually use a computer?
Let me let you in on a secret: The average user doesn't care!
The average user doesn't care how fancy or not a UI looks like, if it follows the interface guidelines. The average user doesn't care if a UI is responsive. The average user doesn't care about smooth animations. The average user doesn't care about slick typography (they prefer horrible Word-Art, Comic Sans and Papyrus). The average user doesn't even care about up-to-the-minute information!
It is developers and people who have an understanding of the problems that must be solved to provide slick animations, responsive UIs, good typography and continuous data updates. Most developers, when thinking about a user think about themselves when they use someone else's product.
My mother already goes off the rails, if an update on her computer just updates one minor detail in the UI toolkits styling. Or if an iconset updates a previously inconsistent or missing icon.
Users care about consistency! It doesn't matter how bad a program is done in a certain aspect, as long it is and stays consistent.
Re: UIs are expected to reflow to devices with different screen sizes and dot pitches.
Most businesses still use desktops and laptops. For something in-house, the extra effort and complexity of reflow may not be worth it.
Most businesses still use desktops and laptops. For something in-house, the extra effort and complexity of reflow may not be worth it.
There were many reasons why Hypercard died:
Hypercard was very much a product of it's time. Software was far less complex so it was much easier to create a general purpose development tool for end users. The author argues that attempts to recreate Hypercard try to do too much, that is because users expect more of software today. To give you an idea of what I mean: I used Hypercard to create a cookbook for a family member in the mid-1990's. You could enter recipes, search for recipes, and even export them to HTML. While this would have been an amazing accomplishment a few years earlier, the program was a relic of a bygone era the moment that it was written. Adding useful features, such as uploading those HTML files to a web server, may have been possible but would have required extensions to the language. Plenty of extensions existed, which is how companies like Cyan managed to produce an amazing for the time multimedia game (Myst) on what most people viewed as a stack of programmable black and white index cards. Yet extending Hypercard to reflect the technology of the 1990's would have transformed a product for everyone to an incomprehensible mass for anyone aside from developers. And the 1990's were primitive compared to the 2010's, never mind the coming 2020's.
In a similar vein, people's interests changed. The mid-1990's brought the web, so people were far more interested in developing for the web. The early days of web development were quite accessible, was focused upon content (much as Hypercard was) and allowed people to embed programs within that content (much as Hypercard did). While Hypercard may have been better for some things and certainly provided a better development environment, it was also obsolete.
As much as I loved Hypercard, the reality is that it was neglected rather than buried. It's longevity could have been improved without increasing complexity, such as adding colour or allowing multimedia files to be embedded (without resorting to third-party extensions). On the other hand, it would have died off eventually. The trajectory of web development shows how a once simple and accessible platform can become so complex that it takes a dedicated student to learn.
Hypercard was very much a product of it's time. Software was far less complex so it was much easier to create a general purpose development tool for end users. The author argues that attempts to recreate Hypercard try to do too much, that is because users expect more of software today. To give you an idea of what I mean: I used Hypercard to create a cookbook for a family member in the mid-1990's. You could enter recipes, search for recipes, and even export them to HTML. While this would have been an amazing accomplishment a few years earlier, the program was a relic of a bygone era the moment that it was written. Adding useful features, such as uploading those HTML files to a web server, may have been possible but would have required extensions to the language. Plenty of extensions existed, which is how companies like Cyan managed to produce an amazing for the time multimedia game (Myst) on what most people viewed as a stack of programmable black and white index cards. Yet extending Hypercard to reflect the technology of the 1990's would have transformed a product for everyone to an incomprehensible mass for anyone aside from developers. And the 1990's were primitive compared to the 2010's, never mind the coming 2020's.
In a similar vein, people's interests changed. The mid-1990's brought the web, so people were far more interested in developing for the web. The early days of web development were quite accessible, was focused upon content (much as Hypercard was) and allowed people to embed programs within that content (much as Hypercard did). While Hypercard may have been better for some things and certainly provided a better development environment, it was also obsolete.
As much as I loved Hypercard, the reality is that it was neglected rather than buried. It's longevity could have been improved without increasing complexity, such as adding colour or allowing multimedia files to be embedded (without resorting to third-party extensions). On the other hand, it would have died off eventually. The trajectory of web development shows how a once simple and accessible platform can become so complex that it takes a dedicated student to learn.
Another thing to think about is the metaphors used. Stacks, cards, and interactive objects on cards were really good metaphors that fit holistically in the Apple personal computing systems of the late 80s/90s. You're right that a lot of the computing environment has changed (eg the Internet is like a natural resource and should be assumed). Whether it is needfully more complex is another matter.
A key question for designers today is this: what are the metaphors that would work for today's computing environments in a similarly holistic way, allowing users to become "authors"? This is something different than a modern Hypercard clone. I think when people want that old "Hypercard feeling," what they really want is this holistic nature, power, and ease of use for regular users -- not simple clones of the old thing.
A key question for designers today is this: what are the metaphors that would work for today's computing environments in a similarly holistic way, allowing users to become "authors"? This is something different than a modern Hypercard clone. I think when people want that old "Hypercard feeling," what they really want is this holistic nature, power, and ease of use for regular users -- not simple clones of the old thing.
Indeed, even HC itself was limited to a subset of the full capabilities of the Mac of its day. To make a successful programming tool "for the rest of us" requires an intuition for what that subset should consist of, on the system where it will live. Too much stuff and it becomes prohibitive to learn. Too little, and it fizzles.
Also, you had to be able to deliver enough value to a user, for them to forgive the aesthetics of your UI, and maybe even your mistakes.
Bill Atkinson may have been a genius, or he may have gotten lucky. Or most likely, both.
If you get the subset right, and make it compelling in other ways, then people will put up with the limitations and even creatively work around them. I think this explains the success of Visual Basic and even moreso, Excel.
Within the context of pre-GUI computers, good old BASIC fits the model.
Also, you had to be able to deliver enough value to a user, for them to forgive the aesthetics of your UI, and maybe even your mistakes.
Bill Atkinson may have been a genius, or he may have gotten lucky. Or most likely, both.
If you get the subset right, and make it compelling in other ways, then people will put up with the limitations and even creatively work around them. I think this explains the success of Visual Basic and even moreso, Excel.
Within the context of pre-GUI computers, good old BASIC fits the model.
When I was a kid, at the beginning of the 00s, and I was beginning to experiment with computers, I imagined the future of computing to be about reducing the complexity of software development as much as possible.
I now realize that I dreamt of something exactly like HyperCards. A world where machines could be programmed using something resembling natural language and where anyone could create and share software.
At the time, the closest thing I could find was a Word document where I dragged and dropped buttons to create a pseudo UI and then imagine that it worked. I wish I had access to something like this.
I believe that by not having a tool like this, we are taking away from the majority of the population, and in particular the young, the possibility of shaping computers for their own needs. A decision has been taken: the user has to be a passive consumer. It's a mistake and I am really sad about it. It feels, to me, as if there was a decision, intentional or not, of keeping the creation of software as a privilege of a few and not a right of everyone.
I believe that by not having a tool like this, we are taking away from the majority of the population, and in particular the young, the possibility of shaping computers for their own needs. A decision has been taken: the user has to be a passive consumer. It's a mistake and I am really sad about it. It feels, to me, as if there was a decision, intentional or not, of keeping the creation of software as a privilege of a few and not a right of everyone.
> It feels, to me, as if there was a decision, intentional or not, of keeping the creation of software as a privilege of a few and not a right of everyone.
It feels that way because that's exactly how it is. If users are creating their own tools and forging their own path it becomes much harder to sell them things and developers aren't in nearly as much demand either. So the groups in the best position to make tools that empower the user are disincentivised to do so.
Theoretically, FOSS would take care of this, right? Only, the people making those tools are quite often also professional developers and so have pretty much the same disincentive. They're ok with making other developers' lives easier, but users? Better remove a few more features from Nautilus lest they get the idea they own their own computer.
It feels that way because that's exactly how it is. If users are creating their own tools and forging their own path it becomes much harder to sell them things and developers aren't in nearly as much demand either. So the groups in the best position to make tools that empower the user are disincentivised to do so.
Theoretically, FOSS would take care of this, right? Only, the people making those tools are quite often also professional developers and so have pretty much the same disincentive. They're ok with making other developers' lives easier, but users? Better remove a few more features from Nautilus lest they get the idea they own their own computer.
It takes a lot of brains, time, money, failure, and just plain screwing around to come up with something like Hypercard or even the earliest personal computing systems. FOSS doesn't allow the time and money part, which is why they are stuck in making "open" tools for advanced teletype emulation. It is not a coincidence that Atkinson made this as an Apple fellow, where he had resources to work on whatever he wanted and could make whatever demands he wanted (and likewise not surprising that Apple could never make HC "profitable")
> A world where machines could be programmed using something resembling natural language and where anyone could create and share software.
This is a silly pipe dream almost as old as computing, which reappears every couple of years in a new guise. When COBOL came out, it was promoted with exactly that promise, and there were people who seriously claimed that within a few years there would be no more professional programmers. More recent incarnations of the pipe dream were "fifth-generation programming languages" and "model-driven development".
In reality, what keeps "the creation of software as a privilege of a few" is not a lack of the right tool, but the lack of the mindset of producing unambiguous, complete instructions and developing your requirements to a state where it's possible to give such instructions, and facing the many mistakes you end up making on the way.
That is actually something very difficult to do, and which Average Joe will never learn, no matter what tools you give him.
This is a silly pipe dream almost as old as computing, which reappears every couple of years in a new guise. When COBOL came out, it was promoted with exactly that promise, and there were people who seriously claimed that within a few years there would be no more professional programmers. More recent incarnations of the pipe dream were "fifth-generation programming languages" and "model-driven development".
In reality, what keeps "the creation of software as a privilege of a few" is not a lack of the right tool, but the lack of the mindset of producing unambiguous, complete instructions and developing your requirements to a state where it's possible to give such instructions, and facing the many mistakes you end up making on the way.
That is actually something very difficult to do, and which Average Joe will never learn, no matter what tools you give him.
A more practical goal is to program in a language or API close to the domain.
Re: I imagined the future of computing to be about reducing the complexity of software development as much as possible.
I've seen the opposite. While we have more choice, all that choice is not been managed well. I now takes much more work to get the same thing. Part of it is that Web standards are lousy for CRUD, and second people have an urge (fear?) to chase fads or be left behind. Simplicity is third fiddle to having the latest.
I've seen the opposite. While we have more choice, all that choice is not been managed well. I now takes much more work to get the same thing. Part of it is that Web standards are lousy for CRUD, and second people have an urge (fear?) to chase fads or be left behind. Simplicity is third fiddle to having the latest.
Amid the ranting, the one thought-provoking statement was this:
> The reason for this is that HyperCard is an echo of a different world. One where the distinction between the “use” and “programming” of a computer has been weakened and awaits near-total erasure. A world where the personal computer is a mind-amplifier, and not merely an expensive video telephone. A world in which Apple’s walled garden aesthetic has no place.
HyperCard made Macs function as personal computers (the original notion behind the term) and not as digital appliances (video editors, gaming rigs, media boxes... etc.)
> The reason for this is that HyperCard is an echo of a different world. One where the distinction between the “use” and “programming” of a computer has been weakened and awaits near-total erasure. A world where the personal computer is a mind-amplifier, and not merely an expensive video telephone. A world in which Apple’s walled garden aesthetic has no place.
HyperCard made Macs function as personal computers (the original notion behind the term) and not as digital appliances (video editors, gaming rigs, media boxes... etc.)
All programming environments do that. And Apple continues to this day to give away a free programming environment for your Mac.
All programming environments do that for programmers. Not all do that for people who aren't software developers.
Case in point: Some of the finance people I work with build incredible spreadsheets. Formulas upon formulas that turn their special spreadsheet into what is really an application. They're programming, but that isn't how they think about it (I've asked). They're just Excel power users.
HyperCard aficionados were the same way. They were programming with the assumption that they just knew HyperCard really well.
You wouldn't be able to sit Douglas Adams (were he alive) in front of XCode and get the equivalent of his HyperCard stack out: https://archive.org/details/DouglasAdamsMegapode
The reason is that it requires a dramatically higher investment to create in XCode. "Just learn Swift" doesn't really cut it as an alternative.
Case in point: Some of the finance people I work with build incredible spreadsheets. Formulas upon formulas that turn their special spreadsheet into what is really an application. They're programming, but that isn't how they think about it (I've asked). They're just Excel power users.
HyperCard aficionados were the same way. They were programming with the assumption that they just knew HyperCard really well.
You wouldn't be able to sit Douglas Adams (were he alive) in front of XCode and get the equivalent of his HyperCard stack out: https://archive.org/details/DouglasAdamsMegapode
The reason is that it requires a dramatically higher investment to create in XCode. "Just learn Swift" doesn't really cut it as an alternative.
It was even clear from the terminology: anyone who made stacks in Hypercard was called an "Author" -- which comprised both "developers" AND users. That naming couldn't be more to the point about the intention of the system.
As an example, a decade ago I taught art students how to code. They had Macintoshes. I had them download Emacs then taught them Emacs Lisp. As insane as that sounds, it was interactive, easy to install, and interesting. They were able to write programs in the REPL after the first class. I wouldn't have dared to have put them in front of XCode or some equivalent IDE.
[deleted]
Why didn't you use MaxMSP or Processing?
A fair question. An easy answer is that I thought Lisp was pretty cool, and that the students were capable of it. And, pragmatically, I was experienced with it, unlike MaxMSP or Processing.
But there was something philosophical: I liked the idea of introducing them to the feel of fundamental computer science, rather than a nice layer over computers for artists. (And what artists actually use those nice layers?) I wanted them to experience an open source ecosystem (unlike Max), and I felt that the Java-base of Procesing was off aesthetically -- too many layers over the machine.
Thinking about the OP, I do wonder what it would have been like to teach coding-for-artists with Hypercard. One thing I love about Emacs Lisp is that it is only grudgingly visual. That it returns computers to something which sends output to a TTY. It gives people who have grown up with a GUI a vision of what computers were like before. I like that Emacs (and Lisp) are things with a history and touch on earlier eras of computer culture.
But there was something philosophical: I liked the idea of introducing them to the feel of fundamental computer science, rather than a nice layer over computers for artists. (And what artists actually use those nice layers?) I wanted them to experience an open source ecosystem (unlike Max), and I felt that the Java-base of Procesing was off aesthetically -- too many layers over the machine.
Thinking about the OP, I do wonder what it would have been like to teach coding-for-artists with Hypercard. One thing I love about Emacs Lisp is that it is only grudgingly visual. That it returns computers to something which sends output to a TTY. It gives people who have grown up with a GUI a vision of what computers were like before. I like that Emacs (and Lisp) are things with a history and touch on earlier eras of computer culture.
Swift is absolutely targeted as an introductory programming language. The same audience that was scripting in Hypercard could grab Apple's Swift Playgrounds iPad app and start learning Swift using neat interactive tutorials today and graduate to writing full-fledged programs. Not only that, but Xcode Playgrounds on the desktop are also a great interactive environment for playing with code, just without the awesome interactive tutorials that Swift Playgrounds on the iPad has.
> The same audience that was scripting in Hypercard could grab Apple's Swift Playgrounds iPad app and start learning Swift using neat interactive tutorials today and graduate to writing full-fledged programs.
You're correct in that some software developers got their first taste of programming with HyperCard, but you're incorrect in that 99%+ of HyperCard users would have zero interest in developing in Xcode (regardless of language).
They are completely different experiences designed for completely different types of users.
You're correct in that some software developers got their first taste of programming with HyperCard, but you're incorrect in that 99%+ of HyperCard users would have zero interest in developing in Xcode (regardless of language).
They are completely different experiences designed for completely different types of users.
I said Swift Playgrounds, not Xcode.
But I also disagree. The people who just dragged around icons in Hypercard and never actually did any scripting, they wouldn't do anything with Xcode, but they're also not the people we're talking about. The people who did learn Hypercard scripting absolutely could do the exact same thing by dragging around buttons in Xcode's Interface Builder and hooking them up with a little bit of Swift scripting. That tutorial about making a calculator in Hypercard, you could do very nearly the same thing in Xcode except for the missing "eval" operator, but that's ok because you can just run each operator immediately (like normal calculators do) instead of building up a long string and then eval'ing the whole thing.
But I also disagree. The people who just dragged around icons in Hypercard and never actually did any scripting, they wouldn't do anything with Xcode, but they're also not the people we're talking about. The people who did learn Hypercard scripting absolutely could do the exact same thing by dragging around buttons in Xcode's Interface Builder and hooking them up with a little bit of Swift scripting. That tutorial about making a calculator in Hypercard, you could do very nearly the same thing in Xcode except for the missing "eval" operator, but that's ok because you can just run each operator immediately (like normal calculators do) instead of building up a long string and then eval'ing the whole thing.
> I said Swift Playgrounds, not Xcode.
You did, but (as you note) Swift Playgrounds don't get you anywhere near the interactive, self-contained experience that users could create and share with HyperCard.
> The people who did learn Hypercard scripting absolutely could do the exact same thing by dragging around buttons in Xcode's Interface Builder and hooking them up with a little bit of Swift scripting.
What you're saying is analogous to saying, "People who learned Excel and VBA could do the exact same thing by creating a web app in Visual Studio Code and hooking it up with a little bit of JavaScript". Yes, conceptually both are "just" programming. In reality, they're worlds apart.
You did, but (as you note) Swift Playgrounds don't get you anywhere near the interactive, self-contained experience that users could create and share with HyperCard.
> The people who did learn Hypercard scripting absolutely could do the exact same thing by dragging around buttons in Xcode's Interface Builder and hooking them up with a little bit of Swift scripting.
What you're saying is analogous to saying, "People who learned Excel and VBA could do the exact same thing by creating a web app in Visual Studio Code and hooking it up with a little bit of JavaScript". Yes, conceptually both are "just" programming. In reality, they're worlds apart.
“Swift Playgrounds don't get you anywhere near the interactive, self-contained experience that users could create and share with HyperCard.”
This. I remember trying Playgrounds when it came out, and it took only minutes to reveal itself as an embarrassing fraud. It pretends to be a persistent environment in the style of Smalltalk systems but it isn’t. Edit a single line of code, and re-executes all of them. Every single time. Utterly useless for exploring stateful systems. Utterly useless as an open environment that users can shape and grow to suit themselves.†
Worse than useless, actually, because it lies to those users just as Tim Cook does.
Hypercard may have had its problems, not least its dour unappealling 1-bit graphic shell, but it was built up from, around, and for users; a depth of design that both reveals and proves itself in use. Software that fits itself to its users; not the other way about. Swift Playgrounds may bring all the shiny, but scratch its surface, step beyond the picturesque preplanned boundaries, and it reveals itself a hollow shell. Canned hype-ware; a dumb monkey-trainer, nothing more. Seymour Papert would’ve garroted it, were he not spinning in his grave instead.
--
†Bonus irony: Swift’s command-line REPL implemented persistency absolutely fine, so there was absolutely no excuse for Playgrounds’ botched cheat. (OTOH, the REPL completely buggers up the “P” bit, making it equally dreadful for non-trivial interactive coding.)
This. I remember trying Playgrounds when it came out, and it took only minutes to reveal itself as an embarrassing fraud. It pretends to be a persistent environment in the style of Smalltalk systems but it isn’t. Edit a single line of code, and re-executes all of them. Every single time. Utterly useless for exploring stateful systems. Utterly useless as an open environment that users can shape and grow to suit themselves.†
Worse than useless, actually, because it lies to those users just as Tim Cook does.
Hypercard may have had its problems, not least its dour unappealling 1-bit graphic shell, but it was built up from, around, and for users; a depth of design that both reveals and proves itself in use. Software that fits itself to its users; not the other way about. Swift Playgrounds may bring all the shiny, but scratch its surface, step beyond the picturesque preplanned boundaries, and it reveals itself a hollow shell. Canned hype-ware; a dumb monkey-trainer, nothing more. Seymour Papert would’ve garroted it, were he not spinning in his grave instead.
--
†Bonus irony: Swift’s command-line REPL implemented persistency absolutely fine, so there was absolutely no excuse for Playgrounds’ botched cheat. (OTOH, the REPL completely buggers up the “P” bit, making it equally dreadful for non-trivial interactive coding.)
There is nothing “introductory” about Swift. It’s a C++ descendant with all the complexity and inconsistency to prove it. All the Playgrounds lipstick in the world doesn’t change the fact it’s a pig, and Tim Cook on stage telling edu customers that Apple created Swift to teach kids to code is just a reminder that Cook is an absolute hack at sales.
..
As for Hypercard, it died because nobody knew how to sell it. No customers, no revenue; no product. Doesn’t matter if you’ve the best technology in the world, it ain’t worth squat if it doesn’t put bums on seats. And while users who did “get” HC really got it, and absolutely adored it as a result, there wasn’t anywhere enough of them to justify its continued existence as part of the Apple product line.
A basic rule of business: learn how to fire your customers. Scrapping niche-appeal distractions that will never drive your major markets is just a subset of that.
https://hbr.org/2011/08/its-time-to-fire-some-of-your.htm
..
As for Hypercard, it died because nobody knew how to sell it. No customers, no revenue; no product. Doesn’t matter if you’ve the best technology in the world, it ain’t worth squat if it doesn’t put bums on seats. And while users who did “get” HC really got it, and absolutely adored it as a result, there wasn’t anywhere enough of them to justify its continued existence as part of the Apple product line.
A basic rule of business: learn how to fire your customers. Scrapping niche-appeal distractions that will never drive your major markets is just a subset of that.
https://hbr.org/2011/08/its-time-to-fire-some-of-your.htm
All sorts of non-techies were able to do that with Hypercard. I remember a shop that had some sort of stock control system the owner had built himself.
Things like PHP, VB and to some extent Excel had some success, but only by forcing the non-technical to become technical. In actuality they're just regular programming with a slightly less steep learning curve. Only Excel escapes this somewhat.
Most IDEs, and XCode have no pretence at catering to user-friendliness or the non-technical. Apart from anything else you have to search for, find, and install XCode from the app store - I know it's not hard, but that's not the point. The learning version of PyCharm for instance just integrates some tutorials. You still have to become a techie to succeed.
There's a distinct hole in the experience in not having Hypercard, or even the simple BASIC of 8 bits ready to go, with examples. It both reflects and reinforces the position as consumption device, and has distanced creation.
Things like PHP, VB and to some extent Excel had some success, but only by forcing the non-technical to become technical. In actuality they're just regular programming with a slightly less steep learning curve. Only Excel escapes this somewhat.
Most IDEs, and XCode have no pretence at catering to user-friendliness or the non-technical. Apart from anything else you have to search for, find, and install XCode from the app store - I know it's not hard, but that's not the point. The learning version of PyCharm for instance just integrates some tutorials. You still have to become a techie to succeed.
There's a distinct hole in the experience in not having Hypercard, or even the simple BASIC of 8 bits ready to go, with examples. It both reflects and reinforces the position as consumption device, and has distanced creation.
>by forcing the non-technical to become technical
Could that be where the actual magic is?
Could that be where the actual magic is?
For the few that do make the leap, sure.
Far more were able to dip into a little ugly BASIC to knock up a menu, calculator or whatever, just as many were able to build surprisingly complex things in Hypercard without ever thinking they made that leap.
I think slowmovintarget has it by saying they never acknowledged they were programming at all. I'd liken it to the kids who were terrible at, and hated maths, but could do frighteningly quick and accurate mental arithmetic when working weekend at their parent's market stall or shop.
Maybe the magic is the ability to hide that you're doing something somewhat technical.
Far more were able to dip into a little ugly BASIC to knock up a menu, calculator or whatever, just as many were able to build surprisingly complex things in Hypercard without ever thinking they made that leap.
I think slowmovintarget has it by saying they never acknowledged they were programming at all. I'd liken it to the kids who were terrible at, and hated maths, but could do frighteningly quick and accurate mental arithmetic when working weekend at their parent's market stall or shop.
Maybe the magic is the ability to hide that you're doing something somewhat technical.
Teachers could create their own grade book apps. Do I put too fine point on it?
I think that is something that we had not seen before and have not seen since.
I think that is something that we had not seen before and have not seen since.
As a teacher, I would love for it to be easier/more intuitive to build my own tools.
I haven't done so recently, but for some time I would look at the latest Mac development tools. They were always just too forbidding. "Hello world" can't require 1000 lines of code, or several pages of instructions to get it working.
Hypercard was a breath of fresh air. Not only could I write useful programs quickly, but I could share them with others, with little risk of mishap. I even wrote software to control rudimentary hardware gadgets using a couple of code resources that I wrote in Pascal.
Today, the point may be moot if Python and Javascript work well enough on a Mac.
Hypercard was a breath of fresh air. Not only could I write useful programs quickly, but I could share them with others, with little risk of mishap. I even wrote software to control rudimentary hardware gadgets using a couple of code resources that I wrote in Pascal.
Today, the point may be moot if Python and Javascript work well enough on a Mac.
That's the thing. In the late 90s if I wanted to make a GUI application that could do a large share of what the overall computing system could do, I had Hypercard. And one didn't even need to study, exactly: all stacks were inspectable and therefore examples of themselves, and examples for learners. You could copy and paste buttons in context. Hypertalk was designed to be easily read (rather than written). Today if a regular user wants to make even a simple GUI, they need to learn a full-fledged programming language just to get started. What a shame!
The last version of HyperCard that was released in 1995 and it was never made PPC native.
VB.Net is still pretty easy.
VB.Net is still pretty easy.
> if Python and Javascript work well enough on a Mac.
They absolutely do not. Even getting started with a GUI app is a major undertaking in either one of those ecosystems.
And that term "ecosystem" indicates the problem, HyperCard was an application for making applications when "application" was just a fancy word for a program with a GUI. Nobody wants to download and learn an ecosystem just to build an app. There should be an app for that, but there's not. We don't have app-building apps on every iPhone because Apple chose not to put app-building apps on every iPhone. It's not hard to see why.
They absolutely do not. Even getting started with a GUI app is a major undertaking in either one of those ecosystems.
And that term "ecosystem" indicates the problem, HyperCard was an application for making applications when "application" was just a fancy word for a program with a GUI. Nobody wants to download and learn an ecosystem just to build an app. There should be an app for that, but there's not. We don't have app-building apps on every iPhone because Apple chose not to put app-building apps on every iPhone. It's not hard to see why.
On Android, the closest thing to an "app building app" is Tasker. It's meant for end-user automation, scripting without much typing, but it's powerful enough to build whole GUI apps (and it wisely offers an option to export such creations as standalone .apks).
It's definitely not Hypercard, but it shares its spirit, and is still a very useful thing. Like, e.g. last weekend I though I'd like to run a sampling profiler on myself - i.e. every now and then pop up a notification to record what I'm doing at any given moment, and store that data in a format I could later use for analysis. I managed to build one in 30 minutes in Tasker - complete with showing the list on a smartwatch and recording to CSV; after first spending the same amount of time looking for existing solutions and failing to find any. That's to show how easy it is to do, straight on your smartphone. It's something you could easily do on a bus or a train - and more importantly, it's something a regular non-tech person could do too.
It's definitely not Hypercard, but it shares its spirit, and is still a very useful thing. Like, e.g. last weekend I though I'd like to run a sampling profiler on myself - i.e. every now and then pop up a notification to record what I'm doing at any given moment, and store that data in a format I could later use for analysis. I managed to build one in 30 minutes in Tasker - complete with showing the list on a smartwatch and recording to CSV; after first spending the same amount of time looking for existing solutions and failing to find any. That's to show how easy it is to do, straight on your smartphone. It's something you could easily do on a bus or a train - and more importantly, it's something a regular non-tech person could do too.
FYI, there is an existing solution that does pretty much what you describe: https://play.google.com/store/apps/details?id=bsoule.tagtime...
Thanks. Interesting, looks like it's being developed by the Beeminder people. I probably would've given it a go if I found it (discoverability of PlayStore sucks), but now my 30-minutes solution is actually more feature-full than this (in particular, it works on a smartwatch).
Ooh, any way we could entice you to describe that in the TagTime forum? https://forum.beeminder.com/c/tagtime
Thanks. This is fascinating.
It's a special case of a more general trend: the complete abandonment of what were once called RAD (rapid application development) tools.
Microsoft also killed WYSIWYG Visual Basic (pre-dotnet), quite possibly the most productive GUI builder ever made. Not quite as clean as hypercard, but another example of that bygone era when the user was the customer and not the product.
The only remaining representative of that era is the spreadsheet, and it seems pretty solidly locked in. Still I do see a push to replace spreadsheets with opaque SaaS tools that do specific things.
Microsoft also killed WYSIWYG Visual Basic (pre-dotnet), quite possibly the most productive GUI builder ever made. Not quite as clean as hypercard, but another example of that bygone era when the user was the customer and not the product.
The only remaining representative of that era is the spreadsheet, and it seems pretty solidly locked in. Still I do see a push to replace spreadsheets with opaque SaaS tools that do specific things.
My first real software dev job was with Visual Basic 3.0, then Delphi 1.0. This World Wide Web thing was about to happen, but hadn't quite yet. Compuserve was where the cool kids hung out, and I ran a WildCat BBS with a buddy out of his basement.
RAD was rad, for a while.
RAD was rad, for a while.
WWW was in effect for many years before 1995, although that was its take off year.
VB.NET is still very productive and outside HN bubble I keep seeing people adopting it when their Excel sheets with VBA macros aren't no longer enough for what they do.
> The only remaining representative of that era is the spreadsheet,
Well that and, Bash, Zsh, Ksh, Perl, Awk, Sed, ....
I sometimes wonder what the world would be like if command lines hadn't stopped evolving in the '90s.
Well that and, Bash, Zsh, Ksh, Perl, Awk, Sed, ....
I sometimes wonder what the world would be like if command lines hadn't stopped evolving in the '90s.
Easy, it would be like Xerox PARC and Lisp Machine REPLs from the 70's and mid-80's.
Which is something that one can come close to with PowerShell, Fish and any IDE based REPL.
Which is something that one can come close to with PowerShell, Fish and any IDE based REPL.
RAD is big business these days, there are whole quadrants of gartner and forester specialized in what RAD is called today: low-code
Check out Logic Apps :)
His acknowledgement of the elephant in the room ("... shit soup of HTML/Javascript/CSS...") is prescient for 2011. Today it's even worse. How many versions of lipstick on pig are we to endure (Backbone, Angular, React, Vue..., Bootstrap, less, sass...) before someone actually makes a sane UI development toolkit?
Think of the children.
Think of the children.
> a sane UI development toolkit?
Elm-lang, IMO.
Elm-lang, IMO.
Elm is sane but IMO not ready and may not be for years. Breaking changes each version, plus a lot of boilerplate have moved me off Elm to preferring TS/React even though I love FP
The problem is the web was designed for documents not apps. And JS wasn’t designed for what it does now. The closest thing we had to a sane development toolkit was Adobe Flex. Someone came up with that and it was ok. But other more powerful forces particularly Apple made it disappear. Google is in charge now maybe it’s up to them.
But a lot of the web is in fact serving documents, and using complicated apps to do it.
It's not surprising, as the two categories do really merge into one another. A web store is certainly an app -- but it's also the modern equivalent of an store catalogue, which is a document.
It's not surprising, as the two categories do really merge into one another. A web store is certainly an app -- but it's also the modern equivalent of an store catalogue, which is a document.
The author seems to attribute malice to the death of Hypercard, something akin to "programmers only stand to lose value if users can help themselves".
I think a far simpler explanation is not that control to the ability to program has been intentionally deprived from users, but rather that the vast majority of users have no wish to have such a tool, and that Steve Jobs recognized this.
I think that some proof of this exists: Excel, Visual Basic (and its formbuilder), Applescript, Autohotkey, etc all exist.
Those tools are all intentionally approachable, as was hypercard, and yet the vast majority of iphone users would not wish to deal with those tools or ecosystems. They would much prefer a company do something called "software development" and give them a working specialized application.
It seems more likely to me that Hypercard was eventually seen as a dead-end, not as a threat to the existence of selling apple software. Sure, you could spend significant effort on building a tool that is powerful for novice users (letting beginners create basic automation and forms easily), but less powerful for experts (providing less powerful design, abstraction, and programming features than more typical programming languages).
I think a far simpler explanation is not that control to the ability to program has been intentionally deprived from users, but rather that the vast majority of users have no wish to have such a tool, and that Steve Jobs recognized this.
I think that some proof of this exists: Excel, Visual Basic (and its formbuilder), Applescript, Autohotkey, etc all exist.
Those tools are all intentionally approachable, as was hypercard, and yet the vast majority of iphone users would not wish to deal with those tools or ecosystems. They would much prefer a company do something called "software development" and give them a working specialized application.
It seems more likely to me that Hypercard was eventually seen as a dead-end, not as a threat to the existence of selling apple software. Sure, you could spend significant effort on building a tool that is powerful for novice users (letting beginners create basic automation and forms easily), but less powerful for experts (providing less powerful design, abstraction, and programming features than more typical programming languages).
I would agree with you and say you can even go further on how people avoid approachable tools. People were asking for something "easier" than HyperCard. Customizing software, rather than learning and programming. Something like HyperStudio "Express" instead of HyperCard. I'm guessing this is why wizards (in Word) also became popular. Though they were meant to teach people concepts, but people ended up using them to avoid learning concepts.
16:38 of this video gives more details of that time when companies started dumbing down things to fulfill customer demand: https://youtu.be/9nd9DwCdQR0?t=998
(The presenters are associated with VPRI, Alan Kay's institute.)
16:38 of this video gives more details of that time when companies started dumbing down things to fulfill customer demand: https://youtu.be/9nd9DwCdQR0?t=998
(The presenters are associated with VPRI, Alan Kay's institute.)
It was apparently gone before Jobs got back, but the same point still stands. The people who put together accounting systems and the like in Hypercard were unusual in being willing (and having the time) to put forth the effort of building anything complex. They're almost certainly the same people who would have put something together in GW-Basic, because they needed what they were building.
I'm a professional programmer, and I've got enough in my plate to be happy to let clients build some portion of things. But they almost entirely won't, even when given software designed to let them do just that. I've never encountered any sort of form-builder or report-generator or whatever that was designed to work for clients "without needing a programmer" where clients didn't end up asking programmers to do all the form-building, report-designing, anyway.
It's like they have jobs of their own to do or something. It's like division of labor makes sense and is inevitable in any non-tiny organisation.
Back when everything was on paper, a technology virtually everyone could access by reading and writing (or typing), lots of people still had specialized jobs based around creating and organizing documents within organizations. Hell, most people are perfectly able to clean and vacuum, but beyond a certain size of 9-to-5 organisation, places hire janitors.
I'm a professional programmer, and I've got enough in my plate to be happy to let clients build some portion of things. But they almost entirely won't, even when given software designed to let them do just that. I've never encountered any sort of form-builder or report-generator or whatever that was designed to work for clients "without needing a programmer" where clients didn't end up asking programmers to do all the form-building, report-designing, anyway.
It's like they have jobs of their own to do or something. It's like division of labor makes sense and is inevitable in any non-tiny organisation.
Back when everything was on paper, a technology virtually everyone could access by reading and writing (or typing), lots of people still had specialized jobs based around creating and organizing documents within organizations. Hell, most people are perfectly able to clean and vacuum, but beyond a certain size of 9-to-5 organisation, places hire janitors.
> But they almost entirely won't, even when given software designed to let them do just that. I've never encountered any sort of form-builder or report-generator or whatever that was designed to work for clients "without needing a programmer" where clients didn't end up asking programmers to do all the form-building, report-designing, anyway.
Did you interface with the individual workers, or company as a whole? My experience is that usually, the software doesn't let workers do what they need, the workers end up working around it with Excel, and at some point information will trickle down through two departments and three layers of managers that some piece of software they're paying for needs adjustment.
> It's like they have jobs of their own to do or something. It's like division of labor makes sense and is inevitable in any non-tiny organisation.
Exactly. But their jobs are almost never correctly captured by software, so people get creative and invent their own workarounds. The unending popularity of Excel is a great example of this. Asking someone else to fix your software for you has large communications cost and time delay; asking programmers has also a large monetary cost.
Did you interface with the individual workers, or company as a whole? My experience is that usually, the software doesn't let workers do what they need, the workers end up working around it with Excel, and at some point information will trickle down through two departments and three layers of managers that some piece of software they're paying for needs adjustment.
> It's like they have jobs of their own to do or something. It's like division of labor makes sense and is inevitable in any non-tiny organisation.
Exactly. But their jobs are almost never correctly captured by software, so people get creative and invent their own workarounds. The unending popularity of Excel is a great example of this. Asking someone else to fix your software for you has large communications cost and time delay; asking programmers has also a large monetary cost.
My experience is that
And mine isn't. Among some of our clients, being able to do anything in Excel is an unusual skill. Among others, they do nothing more than basic spreadsheet work, using nothing more advanced than cross-sheet references. In twenty years of this job, I haven't run into any of the fabled Excel spreadsheet apps. I'm sure they're out there, but I'm also sure there's plenty of the world that doesn't use them.
And mine isn't. Among some of our clients, being able to do anything in Excel is an unusual skill. Among others, they do nothing more than basic spreadsheet work, using nothing more advanced than cross-sheet references. In twenty years of this job, I haven't run into any of the fabled Excel spreadsheet apps. I'm sure they're out there, but I'm also sure there's plenty of the world that doesn't use them.
I think this is more of a cultural shift than anything. Americans in particular used to be tinkerers and makers to a much greater degree. While admittedly many of these examples are influenced by gender roles, it was much more common than today for a mid-century American man to be a tinkerer and handyman who might work on his car in his own garage, do his own home maintenance, and stuff like that. HyperCard and the early days of personal computers arrived at the tail end of this era, where it seemed perfectly natural for "owning a computer" to naturally entail "doing basic computer programming" in much the same way as owning a house, car, or motorcycle entailed doing basic work that entailed having some understanding of the thing. (One complaint you hear about cars these days is that you can't just work on them in your own garage anymore!)
America today is a mass consumer culture where people by and large don't really do that kind of work. Contra Heinlein, Americans today are increasingly specialized insects, less likely to even cook their own meals let alone write a HyperCard stack to manage their recipes. It's in the culture even more broadly than anything Apple might do.
It's not hard to see Apple as making the problem worse instead of better. Apple loves hardware designs that make it impossible to take the machine apart, for instance. Steve Jobs always had that bias--compare the original Macintosh 128K to the Macintosh II, for instance. Even HyperCard itself only came out after Steve left and the hackers briefly took over. And I get it, because a platform that allows for tinkerers and dilettantes is never going to be as beautiful and elegant as a something that was thoughtfully designed from a single perspective; just think back to MySpace or Geocities. But it also makes people dumber in the practical sense of being less capable of changing, repairing, and fully comprehending the world around them.
America today is a mass consumer culture where people by and large don't really do that kind of work. Contra Heinlein, Americans today are increasingly specialized insects, less likely to even cook their own meals let alone write a HyperCard stack to manage their recipes. It's in the culture even more broadly than anything Apple might do.
It's not hard to see Apple as making the problem worse instead of better. Apple loves hardware designs that make it impossible to take the machine apart, for instance. Steve Jobs always had that bias--compare the original Macintosh 128K to the Macintosh II, for instance. Even HyperCard itself only came out after Steve left and the hackers briefly took over. And I get it, because a platform that allows for tinkerers and dilettantes is never going to be as beautiful and elegant as a something that was thoughtfully designed from a single perspective; just think back to MySpace or Geocities. But it also makes people dumber in the practical sense of being less capable of changing, repairing, and fully comprehending the world around them.
Owning a Mac was a very self-selective thing back in the day, and at the time the “bicycle for the mind” ethos was a deep part of Apple’s marketing. HyperCard fit that perfectly. So, if you had the money and inclination to buy a Mac, you were also buying into a philosophy and a promise. That meant that regular people, not professional developers, were engaged and interested in making the most of their (expensive) machines. HyperCard was simple to use, and the return on investment in learning how to build with it was immediately clear.
Imagine you’re a botanist with the spare money to buy a Mac. You could spend a few hours with HyperCard and put together a beautiful plant database, full of pictures and hyperlinks. I love those kinds of stories from the HyperCard era, and it’s a vision of the power of computing that still resonates today, and is a big reason why stories on HyperCard are perennially popular.
In today’s smartphone era we have millions of pre-made apps ready to consume and use. It’s amazing in many ways, but if you think Xcode, or JavaScript and HTML are the natural successors to HyperCard than you don’t really understand what was so magical about HyperCard.
Imagine you’re a botanist with the spare money to buy a Mac. You could spend a few hours with HyperCard and put together a beautiful plant database, full of pictures and hyperlinks. I love those kinds of stories from the HyperCard era, and it’s a vision of the power of computing that still resonates today, and is a big reason why stories on HyperCard are perennially popular.
In today’s smartphone era we have millions of pre-made apps ready to consume and use. It’s amazing in many ways, but if you think Xcode, or JavaScript and HTML are the natural successors to HyperCard than you don’t really understand what was so magical about HyperCard.
Hey, I took some time to write a reply to that post showing a modern day alternative:
https://andregarzia.com/2019/07/livecode-is-a-modern-day-hyp...
I posted another comment linking to a modern day HyperCard that was downvoted without any explanation? I don't understand why it happened. Can someone tell me?
https://andregarzia.com/2019/07/livecode-is-a-modern-day-hyp...
I posted another comment linking to a modern day HyperCard that was downvoted without any explanation? I don't understand why it happened. Can someone tell me?
Hypercard was a very general purpose app, but it was a bit of a "jack of all trades, master of none". I loved Hypercard, but it was never really an actual good solution for any of the things you may want to do with it.
1) Lots of people tried to use it for making games, but anyone who tried quickly ran into its limitations. There were a handful of neat Hypercard games, but when I tried to see how they were made, I saw that they made heavy use of XCMDs and XFCNs -- custom extensions you had to write in a compiled language (Pascal? C?). At that point, why would you bother with Hypercard at all?
2) Another common use case were simple databases, like an address book, or a stack for all your music cassettes, or something like that. But it lacked search tools and a way to work with bulk data, so it wasn't really a good solution for databases. Filemaker was much better for databases.
3) Or you could use it for simple specialized calculators, like a currency converter. But it was a lot of work to set it all up correctly, and Excel was actually a lot more useful for these kinds of tasks.
1) Lots of people tried to use it for making games, but anyone who tried quickly ran into its limitations. There were a handful of neat Hypercard games, but when I tried to see how they were made, I saw that they made heavy use of XCMDs and XFCNs -- custom extensions you had to write in a compiled language (Pascal? C?). At that point, why would you bother with Hypercard at all?
2) Another common use case were simple databases, like an address book, or a stack for all your music cassettes, or something like that. But it lacked search tools and a way to work with bulk data, so it wasn't really a good solution for databases. Filemaker was much better for databases.
3) Or you could use it for simple specialized calculators, like a currency converter. But it was a lot of work to set it all up correctly, and Excel was actually a lot more useful for these kinds of tasks.
> I saw that they made heavy use of XCMDs and XFCNs -- custom extensions you had to write in a compiled language (Pascal? C?). At that point, why would you bother with Hypercard at all?
Hey, don't forget about shareware culture! You didn't need to code up these XFCN/XCMDs yourself. You could try and buy them! There was a whole ecosystem of developers making these things (WindowMaker anyone?) and it worked pretty well for what it was.
Hey, don't forget about shareware culture! You didn't need to code up these XFCN/XCMDs yourself. You could try and buy them! There was a whole ecosystem of developers making these things (WindowMaker anyone?) and it worked pretty well for what it was.
May as well plug a similar article I wrote like 10 years ago now: https://procyonic.org/blog/duckspeak-vs-smalltalk/
I actually passed a few emails back and forth with Alan Kay for this.
I short version of this piece appeared as a letter to the editor in the New Yorker, too.
I actually passed a few emails back and forth with Alan Kay for this.
I short version of this piece appeared as a letter to the editor in the New Yorker, too.
> The certificate for procyonic.org expired on Thursday, June 6, 2019.
> Error code: SEC_ERROR_EXPIRED_CERTIFICATE
> Error code: SEC_ERROR_EXPIRED_CERTIFICATE
Oops! Thanks for the heads up!
1. What's the equivalent of HTML5 canvas in Hypercard?
2. Suppose there's a little dataflow drawing program somebody else wrote in Hypercard. I want to add a binding for my own transient card to pop up on keyboard shortcut, gain focus, steal all input events, then go away on another keyboard shortcut (and return input events to their original bindings). How do I do that?
3. Suppose Hypercard flourished into the 90s and early 2000s. How would this alternate-reality Hypercard have dealt with the pop-up ad problem?
I'm sure there are answers to these questions. However, a theoretical Hypercard that solves them-- plus all the other myriad problems that come from existing on a weaponized internet-- would make this tech much closer to the complexity of the modern web than to the original Hypercard.
2. Suppose there's a little dataflow drawing program somebody else wrote in Hypercard. I want to add a binding for my own transient card to pop up on keyboard shortcut, gain focus, steal all input events, then go away on another keyboard shortcut (and return input events to their original bindings). How do I do that?
3. Suppose Hypercard flourished into the 90s and early 2000s. How would this alternate-reality Hypercard have dealt with the pop-up ad problem?
I'm sure there are answers to these questions. However, a theoretical Hypercard that solves them-- plus all the other myriad problems that come from existing on a weaponized internet-- would make this tech much closer to the complexity of the modern web than to the original Hypercard.
Agreed. I would also argue that spreadsheets serve much of the role that HyperCard was trying to, including many of the problems that a world built on HyperCard would have had. Enormous democratization of computing for the use-cases that can be understood without programming skills, and also enormous amounts of fragility as applications are cobbled together from loose components.
That power comes at a cost. The author covers this when they say open source versions of Hypercard do too much. There is a place for a low powered/low barrier to entry programming environment.
My first forays into computing were Klik n Play and VB6. They let me learn how to solve problems without being overwhelmed with the many things a real Software Engineer needs to deal with.
My first forays into computing were Klik n Play and VB6. They let me learn how to solve problems without being overwhelmed with the many things a real Software Engineer needs to deal with.
For your #2:
HyperCard is primarily mouse-oriented; I don't believe there's a way to add keyboard shortcuts (without writing an XCMD in another language like Pascal). Instead you'd add a button into the other stack (probably on the background) to 'go to "UtilityStack"'.
This would take you to the first card of the stack you'd created, which naturally takes over since it's the one being shown (no need to explicitly 'steal' events). Once you're done there, either use Go > Back (Cmd+B, I believe) or have a button on the card with the script 'go back'. This takes you to the previous card the same way that the back button in your browser would, and likewise events now go to that card with no explicit rebinding required.
HyperCard is primarily mouse-oriented; I don't believe there's a way to add keyboard shortcuts (without writing an XCMD in another language like Pascal). Instead you'd add a button into the other stack (probably on the background) to 'go to "UtilityStack"'.
This would take you to the first card of the stack you'd created, which naturally takes over since it's the one being shown (no need to explicitly 'steal' events). Once you're done there, either use Go > Back (Cmd+B, I believe) or have a button on the card with the script 'go back'. This takes you to the previous card the same way that the back button in your browser would, and likewise events now go to that card with no explicit rebinding required.
I think you could add keyboard shortcuts. You could definitely add menu items (http://folkstream.com/muse/teachhc/menu/menu.html) and you could intercept keydown events at the stack level.
Huh, interesting. They must have added that in a later version than I was using, my copy of "The Complete HyperCard Handbook" doesn't mention "create menu" or keyDown handlers at all. Thanks for the correction!
> 1. What's the equivalent of HTML5 canvas in Hypercard?
Scripting the paint tools. A practical example:
A keyDown handler in the Home stack and "push/pop card", probably. There isn't really any way to make a card appear on top of another card, though.
> 3. Suppose Hypercard flourished into the 90s and early 2000s. How would this alternate-reality Hypercard have dealt with the pop-up ad problem?
Poorly. The merryXmas worm comes to mind.
Scripting the paint tools. A practical example:
set userLevel to 3 -- "Painting"
choose select tool
set cursor to blank
drag from 0,0 to 100,100
doMenu "Select"
set dragSpeed to 150
drag from 40,50 to 480,125
set lockscreen to true
set cursor to blank
doMenu "Select All"
doMenu "Revert"
choose browse tool
A keyDown handler in the Home stack and "push/pop card", probably. There isn't really any way to make a card appear on top of another card, though.
> 3. Suppose Hypercard flourished into the 90s and early 2000s. How would this alternate-reality Hypercard have dealt with the pop-up ad problem?
Poorly. The merryXmas worm comes to mind.
Another article that pops up regularly on HN, on this relevant topic:
The coming war on general-purpose computing
(previous discussion: https://news.ycombinator.com/item?id=19872364)
There are a number of admirable attempts to create the "next Hypercard" on the web. I haven't encountered one that really sticks, but as an old(er) timer who remembers the earlier era of personal computers - where the user was really the user, not "used" - I see that it's an important dream to keep alive, especially in our current cultural context of an increasingly exploitative web.
The coming war on general-purpose computing
(previous discussion: https://news.ycombinator.com/item?id=19872364)
There are a number of admirable attempts to create the "next Hypercard" on the web. I haven't encountered one that really sticks, but as an old(er) timer who remembers the earlier era of personal computers - where the user was really the user, not "used" - I see that it's an important dream to keep alive, especially in our current cultural context of an increasingly exploitative web.
Loper-os seems to suffer from the same problems as a lot of "unix hater"/lisp weenie types: while he does point out real flaws in the computing of today, he seriously lacks in a competent, coherent, non-vaporware alternative. His blog is now nothing but bloviating about bitcoin
As a not-fully-recovered Lisp weenie, I give a lot more slack to other wild-eyed idealists than I used to.
Like, he's not wrong. I also had a HyperCard experience about that age, and it definitely was a significant factor years later.
So he doesn't have an alternative. So what? Do you have one for cancer? It's still worth something to avoid Stockholm Syndrome.
Like, he's not wrong. I also had a HyperCard experience about that age, and it definitely was a significant factor years later.
So he doesn't have an alternative. So what? Do you have one for cancer? It's still worth something to avoid Stockholm Syndrome.
[deleted]
If you need to use the term "sniveling digital trendoids", then your argument probably isn't as good as you think it is. (The author, not you.)
Author of linked site speaking. Are you sure you are reading the same page? I had half a dozen articles re Bitcoin, the last in 2014...
Your most recent article, http://www.loper-os.org/?p=3440 is tagged bitcoin, and in fact if I click on the tag, I see an awful lot of articles written in the last few months http://www.loper-os.org/?cat=42
I do have a multi-chapter series on constant-time integer arithmetic -- indeed tagged incl. "bitcoin", as it is meant to be used in (among other places) a rework of the client.
You evidently spent at most 3 seconds reading the link; wouldn't kill you to spend 5 seconds and see what is behind the tag.
You evidently spent at most 3 seconds reading the link; wouldn't kill you to spend 5 seconds and see what is behind the tag.
This is a pretty incendiary and bitterness-laden rant. I enjoyed the trip back in time but the last paragraph, for me, pretty much nullified any actual points the author was trying to make.
I empathize with your feelings, but iobjectively, if an author makes three good points and then pours toxic emotional sewage all over them, the good points are still the gooid points.
We may not want to read the author esposuing them any further, who needs toxic sewage? But the sewage cannot nullify a point that we recognize as true. Its truth is independent of whether the author is a goofd or bad person. Its truth is independent of whether the author argues it well or poorly.
It's unfortunate when good points get covered in toxic emotions. I wouldn't say that we should read such things whether we like it or not, but having read them, I say we take the good points and repackage them in less vitriolic prose.
We may not want to read the author esposuing them any further, who needs toxic sewage? But the sewage cannot nullify a point that we recognize as true. Its truth is independent of whether the author is a goofd or bad person. Its truth is independent of whether the author argues it well or poorly.
It's unfortunate when good points get covered in toxic emotions. I wouldn't say that we should read such things whether we like it or not, but having read them, I say we take the good points and repackage them in less vitriolic prose.
It undermines his judgement. He makes sweeping, subjective arguments, which isn't inherently a bad thing but it means those arguments are more than just cold facts. The amount of heated emotion he apparently has around this subject means that his ability to draw conclusions from "soft" information is compromised.
If we’re talking about a syllogism, fine. If we’re talking about some mixture of logic with historical recollections, suppositions about other peoples’ state of mind, etc... the narrator starts to matter more. If I can trust him to be objective and reasonable, it weakens the piece.
Points made through the application of logic can't be nullified by a failure to appeal to emotion. The writing style may not be optimal for building consensus, but that won't make it invalid.
I agree, and contrary to the two other responses, I can't separate the toxic emotion stuff from the supposed neutral argument underneath it. Why? Well, I have only vague memories of Hypercard (played with it as a kid), so when you read the arguments about it from someone who clearly knows a lot more, you're expected to take it on authority.
However, if that person is ranting and raving and calling people who disagree with him "autistic", it's impossible not to suspect that the guy has the 'thumb on the scale' even in the portion of the discussion that's apparently neutral. As someone pointed out in his comment section, he was just plain making stuff up about Jobs killing Hypercard (despite his attempts to back-and-fill on the issue).
However, if that person is ranting and raving and calling people who disagree with him "autistic", it's impossible not to suspect that the guy has the 'thumb on the scale' even in the portion of the discussion that's apparently neutral. As someone pointed out in his comment section, he was just plain making stuff up about Jobs killing Hypercard (despite his attempts to back-and-fill on the issue).
Discussed at the time: https://news.ycombinator.com/item?id=3293657.
I also had an early accidental contact with HyperCard, and sort of learned the basics without knowing it. I was looking for something equivalent to show my 12 year old, who is into Minecraft and generally open minded about learning geeky stuff (they've had Sketch and electronics basics in school, likes to plays with LEDs, 3d print, etc). I found Sketch a bit too limited, despite a few attempts, it didn't work out for me.
I don't know much about game programming, but we ended up exploring Unity 3D. There are tons of videos online, it works well under Linux, and you can do lots of different things with limited programming. Probably not perfect, it's just for playing around, but curious to hear other experiences.
I don't know much about game programming, but we ended up exploring Unity 3D. There are tons of videos online, it works well under Linux, and you can do lots of different things with limited programming. Probably not perfect, it's just for playing around, but curious to hear other experiences.
PICO-8 might be worth investigating. It attempts to capture the experience of hacking on an 8-bit computer rather than something higher level. Also, it's cheap but not free.
https://www.lexaloffle.com/pico-8.php
https://www.lexaloffle.com/pico-8.php
If Unity worked out well then Godot could be a good choice. It’s conceptually simpler but is still very powerful.
I had just signed in to suggest Godot myself. :)
For the GP, here's the Godot web site: https://godotengine.org/
While Godot has its idiosyncrasies, in terms of being a tool that made it possible to actually get something done and playable, I've been pleased with the results I've gotten from it so far.
The ability to export to HTML5 in addition to desktop & mobile is great for getting a project in front of people quickly--particularly useful for things like game jams: https://rancidbacon.itch.io/sheet-em-up (which I created as my first game jam entry :) ).
Godot is also released under a MIT license and has multiple full-time developers working on it (supported in part by monthly community donations).
For the GP, here's the Godot web site: https://godotengine.org/
While Godot has its idiosyncrasies, in terms of being a tool that made it possible to actually get something done and playable, I've been pleased with the results I've gotten from it so far.
The ability to export to HTML5 in addition to desktop & mobile is great for getting a project in front of people quickly--particularly useful for things like game jams: https://rancidbacon.itch.io/sheet-em-up (which I created as my first game jam entry :) ).
Godot is also released under a MIT license and has multiple full-time developers working on it (supported in part by monthly community donations).
Here's what Atkinson said about it in 2002:
https://www.wired.com/2002/08/hypercard-what-could-have-been...
More clues in this (2016?) Twit interview (including the phrase 'Sculleystink' at about 16m in):
https://www.youtube.com/watch?v=INdByDjhClU
https://www.wired.com/2002/08/hypercard-what-could-have-been...
More clues in this (2016?) Twit interview (including the phrase 'Sculleystink' at about 16m in):
https://www.youtube.com/watch?v=INdByDjhClU
I am a fan of Leo, but he also tends to fall on my nerves with constantly interrupting people. Atkinson is great in just not letting that happen, FUN!
I think Web killed Hypercard. Hypercards were kind of components and that was their power. Create onbe card at a time then connect them together. But so were/are web-pages.
But you could not connect a hyper-card to another card created by another author executing on another machine. That was the mind-blowing concept of web and it quickly became clear that that is what we wanted to do, not dabble with our own stack of "hyper" cards.
For one thing web was not tied to Apple hardware
But you could not connect a hyper-card to another card created by another author executing on another machine. That was the mind-blowing concept of web and it quickly became clear that that is what we wanted to do, not dabble with our own stack of "hyper" cards.
For one thing web was not tied to Apple hardware
Hypercard's "letting regular people build useful things" ethos lives on in IFTTT, Zapier and Microsoft Flow. In 2019, it's not super useful to many people to be able to mush together some buttons and textboxes into a desktop UI, but it's fantastically useful to be able to mush together their email, calendar, SMS, Instagram, Facebook, Twitter, Dropbox, Spotify, Alexa, home automation etc.
The fact that stuff that used to be on local files is now inside these various services makes it _much harder_ to bootstrap together simple programs I think.
Though on the other hand if you leverage some other automation tools you can avoid figuring out how to auth to various systems yourself. You just end up contributing to the "everything is connected by duct tape" nature of modern software
Though on the other hand if you leverage some other automation tools you can avoid figuring out how to auth to various systems yourself. You just end up contributing to the "everything is connected by duct tape" nature of modern software
Sorta, kinda, not quite.
That's the problem with SaaS - they take your data, silo it up, and expose through highly limited and tightly controlled APIs. Sure, I can make IFTTT save a copy of every picture I upload to Facebook into my Dropbox account (or at least I could, I think it broke). But I can't make it save that picture in original size, because someone didn't expose some option, or an endpoint. Or I can't make IFTTT save all the reactions to my post into a CSV in the format: <<datetime, which post, who, what reaction>>, because such endpoints again aren't exposed or integrated. Etc.
I get that IFTTT & folks are doing the best they can, but the companies they're trying to "mush together" made their money on preventing interoperability, so it's still very far from both what could be and what used to be possible.
That's the problem with SaaS - they take your data, silo it up, and expose through highly limited and tightly controlled APIs. Sure, I can make IFTTT save a copy of every picture I upload to Facebook into my Dropbox account (or at least I could, I think it broke). But I can't make it save that picture in original size, because someone didn't expose some option, or an endpoint. Or I can't make IFTTT save all the reactions to my post into a CSV in the format: <<datetime, which post, who, what reaction>>, because such endpoints again aren't exposed or integrated. Etc.
I get that IFTTT & folks are doing the best they can, but the companies they're trying to "mush together" made their money on preventing interoperability, so it's still very far from both what could be and what used to be possible.
You could try nodered-self hosted or cloud options. It has plugins for most stuff including GPIO, MQTT, HTTP, email, twitter.
https://nodered.org/
https://nodered.org/
[deleted]
Business and engineering rarely goes hand in hand. So you made something that never wear and tear, boss orders you to redo the formula so it has to be replaced more often, resulting in more sales. Or you made something that enables the user to create infinitely amounts of what your company sell, boss tells you to erase all copies of it. etc.
"If you disagree with my barely-argued opinion, you're autistic" isn't a great way to close an article
Hypercard was obsoleted by the www. To survive it would have had to become a visual HTML editor. If you are looking inside the Microsoft backcatalog it is not VB that was the Hypercard heir, it was Frontpage for consumer-and Infopath for business applications.
archive.org now has the ability to run uploaded Hypercard stacks in your web browser.
Example:
https://archive.org/details/hypercard_autodiagnostics-25
Example:
https://archive.org/details/hypercard_autodiagnostics-25
I tried to get a license for SuperCard (it had color), but had to use resedit + HyperCard to add color textures... Miss those days (not so much)
off topic (but same era) I loved MacProject... yet another Claris step child software. Moof!
(https://en.wikipedia.org/wiki/MacProject)
off topic (but same era) I loved MacProject... yet another Claris step child software. Moof!
(https://en.wikipedia.org/wiki/MacProject)
Hey I just noticed that SuperCard is still alive and offers HyperCard migrations:
https://www.supercard.us/
(SuperCard was a commercial HyperCard alternative)
https://www.supercard.us/
(SuperCard was a commercial HyperCard alternative)
I spent a lot of time as a 7 year old playing around with Hypercard. Gave me a lot of good early exposure to building interfaces.
Okay this may be unpopular, but I felt like Microsoft VB 3.0 (for me) was a better version of HyperCard on a worse platform.
I wonder why there was a "Scripting language" dropdown menu, was anything but HyperTalk ever possible?
From my perspective, HyperCard lives on in 2 distinct branches: webapps and PowerPoint.
LiveCode is pretty nice. If you want something fast & crossplatform it is kind of hard to beat. I find the language awful (far too verbose for my taste) but I would say most people here would have that going in 1 to a few days to be productive. The forum is active and people answer fast when stuck.
How hard would it be to port HyperCard to Qt? No reason we can't have it back.
If the LiveCode people can get HyperCard running on *nix, I'm sure HyperCard could be ported to Qt.
https://en.wikipedia.org/wiki/LiveCode
https://en.wikipedia.org/wiki/LiveCode
I could imagine Playgrounds app turning into such a thing
[deleted]
Uhm, I have grown up with Macintoshs and I still use them. So, my comment has at least double the emotional intensity compared to the author's. ;-) In all seriousness, I say this because it is clear that his post is mostly based on an emotional attachment to a tool, not on critical thinking.
Maybe I misunderstood, but if I understood him correctly, the premise is that Hypercard would still be around if it did not collide with Steve's vision of a world of dumb users and smart engineers. This is wrong on so many levels, I don't even know where to start. Are you willing to learn?
First, Hypercard was created when 13" 256-color displays were state of the art (actually even earlier) and there were exactly two devices to interact with your Macintosh: a keyboard and a mouse. So, for simple tasks, it was quite easy to create a tool that would allow you to stick together a simple program using clicks and a verbose scripting language. Nowadays, however, general purpose applications are supposed to work on a variety of devices, from 4" phones with touchscreens to desktop-Macs supporting 27"+ screens being used with traditional keyboards and mice. Maybe this will change in the future, but if you want to precisely describe a structure (GUI-compontents) in a generalized fashion, a textual representation (e.g. react-components), so far, is just superior to any GUI-tool that is around.
When hypercard was created, VCS (such as git, svn, etc.) weren't really a thing. Most software was developed in about the same way as you created Hypercard projects: You made changes to your main copy and that's that. Today, you don't even think about starting a software project without having vcs in place. Similarly, when Hypercard was created, many software methodologies weren't a thing: Unit Testing, Integration testing, etc.
Now, I am a software engineer, and while I never wrote Hypercard applications myself, I once found myself maintaining an Filemaker-Application. Filemaker, I reckon, is very similar to Hypercard in that you plug together your app using a GUI and some overly verbose, pseudo-simple scripting language. And, needless to say, this was an absolute disaster: In the beginning, it was a simple tool that automated a couple of tasks and it was created in a very short period of time, thanks to the easy-of-use of Filemaker. However, as with all other tools, it grew in complexity. Now, ever tried to track changes in the source code using Filemaker-files? Ever tried to unit test Filemaker-code?
And don't get me started with the absolute ludicrous idea to use programming languages that resemble a natural language. Claiming that this is as effective as using an abstract language is akin to describing complex mathematical facts using only a natural language—while possible, it is completely unfeasible.
Maybe I misunderstood, but if I understood him correctly, the premise is that Hypercard would still be around if it did not collide with Steve's vision of a world of dumb users and smart engineers. This is wrong on so many levels, I don't even know where to start. Are you willing to learn?
First, Hypercard was created when 13" 256-color displays were state of the art (actually even earlier) and there were exactly two devices to interact with your Macintosh: a keyboard and a mouse. So, for simple tasks, it was quite easy to create a tool that would allow you to stick together a simple program using clicks and a verbose scripting language. Nowadays, however, general purpose applications are supposed to work on a variety of devices, from 4" phones with touchscreens to desktop-Macs supporting 27"+ screens being used with traditional keyboards and mice. Maybe this will change in the future, but if you want to precisely describe a structure (GUI-compontents) in a generalized fashion, a textual representation (e.g. react-components), so far, is just superior to any GUI-tool that is around.
When hypercard was created, VCS (such as git, svn, etc.) weren't really a thing. Most software was developed in about the same way as you created Hypercard projects: You made changes to your main copy and that's that. Today, you don't even think about starting a software project without having vcs in place. Similarly, when Hypercard was created, many software methodologies weren't a thing: Unit Testing, Integration testing, etc.
Now, I am a software engineer, and while I never wrote Hypercard applications myself, I once found myself maintaining an Filemaker-Application. Filemaker, I reckon, is very similar to Hypercard in that you plug together your app using a GUI and some overly verbose, pseudo-simple scripting language. And, needless to say, this was an absolute disaster: In the beginning, it was a simple tool that automated a couple of tasks and it was created in a very short period of time, thanks to the easy-of-use of Filemaker. However, as with all other tools, it grew in complexity. Now, ever tried to track changes in the source code using Filemaker-files? Ever tried to unit test Filemaker-code?
And don't get me started with the absolute ludicrous idea to use programming languages that resemble a natural language. Claiming that this is as effective as using an abstract language is akin to describing complex mathematical facts using only a natural language—while possible, it is completely unfeasible.
Where is the eval call in the hypertalk script? Is it "value of" applied to a string, i.e. "value of value of card field"? (I assume it's not simply "value of" since that doesn't seem like it would work for the operator buttons in the example - or does "/" or "+" evaluate to itself?)
This seems like a good reason to kill the language at least, in the Internet-connected era. In a language that's supposed to read like English, eval should be "dangerously execute untrustworthy text from ... as program instructions" or something, not a polymorphic call to a common operator accidentally applied to the wrong type.
This seems like a good reason to kill the language at least, in the Internet-connected era. In a language that's supposed to read like English, eval should be "dangerously execute untrustworthy text from ... as program instructions" or something, not a polymorphic call to a common operator accidentally applied to the wrong type.
The fallout from being able to used to cause people to suffer brain damage when opened also probably contributed
There still is no free development tool out there that matches what Hypercard did in terms of power and ease of use. We're still coding with languages designed for constraints that disappeared decades ago.