Why Hypercard Had to Die (2011)
loper-os.org
loper-os.org
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.
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.
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"
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.
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.
(Pre-Edgmium, Edge's Dev Tools even shared a bunch of code with VS Code and briefly explored hosting a full VS Code experience.)
::ye olde Mozilla Composer appears directly::
No you wouldn't, but you can ;) How high is your tolerance today?
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 doubt Hypercard would have ever gotten anything like CSS. It was unlikely enough that CSS ended up anything like CSS!
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.
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 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.
From Dutch you can switch to English using the menu in the top right corner (click "Engels")
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.
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
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.
PS: Disclaimer, I work for them.
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.
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?
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.
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.
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.
I can dream anyway.
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 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.
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.
Did it, really? I still find it amazing. I did wonders with the lightweight version of it that came with Claris/Apple Works
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".
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 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
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.
There are many companies using it.
The main modern difference between ye-olde hypercard and vb, is that the whole ecosystem was a monolith, whereas now it's disconnected.
Hypercard predates VisualBasic by many years
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
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.
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.
[1] See related article by same author: http://www.loper-os.org/?p=316 On the Still-Undefeated Tyranny of Apple.
> 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.
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
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.
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.
Most businesses still use desktops and laptops. For something in-house, the extra effort and complexity of reflow may not be worth it.
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.
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.
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.
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 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.
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.
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.
> 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.)
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.
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.
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.
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.
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.
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.)
..
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.
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.
Could that be where the actual magic is?
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.
I think that is something that we had not seen before and have not seen since.
Yes. And perhaps the last major remnant of this once prominent philosophy on what personal computing should be about.
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.
VB.Net is still pretty easy.
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.
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.
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.
RAD was rad, for a while.
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.
Which is something that one can come close to with PowerShell, Fish and any IDE based REPL.
Think of the children.
Elm-lang, IMO.
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.
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).
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.)
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.
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.
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.
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.
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.
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?
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.
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.
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.
> Error code: SEC_ERROR_EXPIRED_CERTIFICATE
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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).
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):
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
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
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.
Example:
off topic (but same era) I loved MacProject... yet another Claris step child software. Moof!
(SuperCard was a commercial HyperCard alternative)
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.
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.