LiveCode can import HyperCard stacks. You'll need to use LiveCode version 6, since the HyperCard import functionality has been broken in LiveCode 7 onwards, but you can import a HyperCard stack using LiveCode 6, save the project in LiveCode's file format, and continue in a recent version of LiveCode.
HyperTalk and LiveCode aren't 100% compatible (probably around 80%, less if you used a lot of XCMDs since they aren't supported), but if you have an old stack you want to modernise, LiveCode is a great and affordable (it's GPLv3, with a commercial offering if you need to publish closed source projects) way to do it.
The best resource[1] on converting a HyperCard stack to LiveCode is by Jacqueline Landman Gay of HyperActive Software[2]. I believe HyperActive can also do consulting and conversion work for HyperCard stacks to LiveCode.
Oh man, I will have to try this. I have a TON of stacks that I made as a kid, would be fun to play around with them in a better environment than SheepShaver.
In the spirit of HN contrarian comments, I'd say the closest thing spiritually to a modern-day HyperCard is PySimpleGUI:
https://github.com/PySimpleGUI
Previously the closest thing to HyperCard was WinForms, which PSG borrows heavily from. PSG is probably the fastest way for anyone moderately familar with python to throw together an ugly-but-servicable GUI program and I reach for it when I'm in a hurry. The two tricks behind PSG are: 1. very concise and memorable GUI layout with only python code and 2. use of an event loop instead of handlers. All of this sounds pretty basic and obvious, but no one else does it this way.
How is the closest thing to HyperCard when you need to type code to make the GUI? In HyperCard you draw the interface as if you were using a paint program, you create simple databases "living" inside the stack just by placing input fields around and you create links by placing buttons that you can make links to the other cards just by visiting them. You can make presentations, e-books, simple databases like phone books, recipe books, etc without writing a single line of code. And if you want to write some code the language is very simple and "readable" with very simple approachable commands and a GUI that 'knows' about it.
I added the weasel-word "spiritually" for that reason. If I had a teenager wanting to make a gui program I would point them to PSG as it doesn't require much conceptual understanding nor many lines of code to bang something together. There are still graphical programming environments out there and there is even a general one in the form of LabVIEW community edition. However, they just don't have the network effect of Python which is the de facto "learn to program" language.
But HyperCard wasn't really for making GUI programs - i do not even think many people who used it viewed themselves as programmers (at least not any more than people who make complex stuff on Excel do). Sure, you can place buttons and input fields, but it was more of a hyperlinked painting program that also allowed you to enter interactive elements.
I think it was closer to something like Powerpoint (which i think also allows you to put interactive elements and jump between slides) and Access (though actually Microsoft Works' database is much closer to it) than even Visual Basic (as was mentioned in another comment).
As someone who made a great many HyperCard stacks, I like this characterization:
> I think it was closer to something like Powerpoint (which i think also allows you to put interactive elements and jump between slides) and Access
Hypercard occupied this weird in-between space. It was kind of a programming thing, but not exactly. You could certainly program it. And it could load XCMDs and XFCNs to expand the universe of things you could do with it. But it was a lot like PowerPoint too. I wasted a ton of time playing with transitions (dissolve, fade, swipe up, swipe across, etc) between cards.
I think HyperCard was the last thing of its kind. By that I mean its a throwback to when the default assumption was that anyone who bought a computer was, as a matter of course, going to program it. The same way many machines in the 1980s booted into BASIC interpreters and pretty much all of them included one in the default environment. HyperCard was the last effort that I can think of to take that idea and make it accessible to people who didn't know what "programming" was.
The last macs that shipped with it were, IMO, the last computers that came, by default, with everything their users needed to create and distribute programs for them and the assumption that most of their users would do just that.
I'm not sure that idea can be replicated anymore. I'm sure it can't, at scale.
> As someone who made a great many HyperCard stacks...
I don't suppose you still have the files for those stacks lying around? I maintain the HyperCard Online project, a collection[1] of over 3,500 HyperCard stacks on the Internet Archive directly emulated in-the-browser.
I've made an uploader[2] that anyone can use to contribute their own stacks to the collection. It accepts all formats of stacks (all the .sit, .bin, .hqx-style compression formats that were common in the 80s/90s, disk images, and just raw HyperCard stacks).
It's always great to see what stacks folks are uploading - recently a large number of Japanese stacks were uploaded, covering a wide range of topics.
I still do have some, I think, but I'm not sure I can currently extract them from the floppies and/or syquest cartridges I saved them on. I will scour my drives and upload any I can find.
This is the first time I've seen your project, and I love it!
The two that I would most like to find and post online were
* A matrix math tool
* A gadget that monitored a serial port for errors from a giant, industrial label printer
I also had one that was very similar to the then-popular tool BackOrifice but for macs of the day.
If I can get any of them onto a modern system I will definitely upload :)
That would be awesome! Those sound like some really interesting stacks - particularly the industrial monitoring one, as there currently aren't many stacks like that in the collection.
I'm happy to answer questions about moving stacks from old media onto more modern systems - there are a few 'gotchas' particularly due to the way old Macs used resource forks and new systems... don't. Email hypercardonline@gmail.com
I like the way you contextualize this. What's interesting is to contemplate that Macs still come with / have free access to Xcode and apps like Developer and Swift Playgrounds, which would seem to fit into what you are saying above in terms of free tools assuming the purchasing user wants to program. But what tools like that say about the complexity of modern programming vs. the wonderful simplicity of HyperCard is an interesting philosophical exercise.
There's the complexity difference, for sure. But the thing that's standing out to me right at the moment is the fact that the mac I got in 1991 just assumed I was going to use HyperCard. The same way the one I got in 2015 assumed I was going to want to use Keynote or Numbers.
HyperCard was a weird beast. While it was a programming tool, it wasn't the kind of programming tool people who programmed for a living were, by and large, using to build the applications they were selling.
(Make no mistake. Some did build the applications they sold with HyperCard. I built and sold one that way. See also Myst.) The tools that currently come free with any OS X license (or Windows, in the case of VS community editions, the sdk, and VS Code) are the tools that real working programmers use to build the things they sell. And it's real working programmers that pick those tools up.
The spirit I remember for HyperCard was: you have this computer now. You're going to want to program it. Here's a thing that does that. The business end was absent. People bought computers to create things, and one of the things you'd create is a program.
And, just to be clear, I'm not waxing nostalgic for 90s programming. Programming and the tooling that enables it are clearly better in pretty much every way now for people who know they want to do that.
I'm nostalgic for this bit of programming tooling that was intended for non-programmers and is now quite obscure. (See: livecode) That is unfortunate because much of its virtue used to lie in the fact that it was just __there__ by default when you fired up a new computer.
OmniGraffle can be used to scratch some of the many needs that HyperCard fufilled.
Shapes can trigger not just navigation or show/hide but also AppleScripts. Can be quite useful to throw together a quick MVP, which HyperCard was awesome for.
It's been awhile since I've messed with a GUI in python, so I did quick image search to see just how ugly it is. And it actually looks very serviceable. A bit utilitarian, perhaps, but not too bad. I was expecting much worse, like the old Tk dialogs. And judging by the variety of examples I found, it can be themed to some degree. My only problem - and what has driven me to use web apps in the past - is the difficulties in bundling and distributing python apps.
Something I've learned in my old age is that merely ugly is still better than anything I'm likely to come up with myself. If something threatens to be interesting enough to distribute, the marketeers will never let me decide how it's going to look anyway. For the work that I do, not having to think about layout or aesthetics at all is a time saver with virtually no downside.
After using REBOL, I found the "standard" GUI functionality in Python for creating interfaces so unhappy I used pyPEG to write a DSL parser that would turn REBOL-style interface descriptions into introspective wxPython GUI's.
I say REBOL-style, since it was superficially similar to REBOL (or REBOL/VID, if you prefer), the full power of the Visual Interface Dialect requires an actual REBOL interpreter...! Instead, I used mostly static layouts and a simple escapement to call Python handlers as necessary.
Every time when someone opens a dialog and write small script into it I wonder how does this work for large/complex project? Normally we have a file(s) with many functions so we can search/replace across all of them. This is a problem with many today's productivity tools as well. Looks splendid until it becomes large. Any solution?
Calls to handlers/functions (usually) pass through what is called "the message path", going from object -> grouped objects -> card -> substack -> stack. This path is also enhanced by frontscripts and backscripts (code placed in the path either before the initial object or behind the stack).
So well-organized code does not have to be scattered among 100s of objects, but is instead centralized and placed in the most appropriate location.
In 2016 "script only stacks" were introduced. The normal stack is a binary file containing code and GUI elements. The script only stack is a text file, meaning it can be diffed and put under normal version control.
Since you work for LiveCode, do you know if there are any plans to implement platform accessibility APIs, so LiveCode (or at least applications built with it) can work with assistive technologies, such as screen readers for blind people? Besides being the right thing to do, that might unlock some sales to the educational market.
That's a great question. Im interested in visual coding tools but, probably in my ignorance, I wonder how any of them work for keyboard and/or screen reader users.
To be clear, the problem isn't just the drag-and-drop nature of the development environment. The whole GUI toolkit is completely inaccessible with a screen reader.
Sorry, that article is from 2019, I don't work there anymore so I can't tell. I'm a customer though and have been developing with the language since forever, what we usually do when we want such answers is to post to either the mailing list or the forum. Another option is emailing support, they're a small company but they take support seriously and will answer.
Thanks for posting it. I don't think I've looked at this set of tools since it was Metacard.
I love these threads every time they come up. Mostly because I loved HyperCard.
Without fail, everything suggested as a modern HyperCard replacement really nails at least one element of its spirit and really misses something else.
I think this is one of the closer ones overall. Its adherence to the stack model is much closer than the others and its programming language certainly is closer to HyperTalk than any other I recall, besides AppleScript.
Your walk through showcases the similarity really nicely.
It even looks like you can write the spiritual equivalent of an XCMD.
I think where LiveCode misses the boat is the packaging step necessary for distributing your "Apps". With HyperCard, we passed around stack files. And unless we took some special steps to prevent it, they were also the preferred form for editing our programs. So if I gave my stack to you, you could run it as a program. But you could also edit and change it.
That default, where I could throw the exact thing I was working on onto a floppy and hand it to my dad, who could run it on his machine but also edit it if he wanted to is something I really haven't seen replicated.
Maybe that's a side of HyperCard that just can't be recreated today. Or just shouldn't, until the tooling to run the "stacks" gets distributed by default with a major OS.
Thanks for causing a fun re-exploration of a space that was really influential for me.
As for distribution, you can still distribute stacks and people who have livecode can run it without fuss. That still works. One unique feature from livecode is its ability to cross-compile a standalone and I decided to demo that in the post because I felt many people would like to distribute applications, that dosn't mean it is the only way to do it.
A technique that many of us use is having a "loader stack" which just load a stack from disk or network, then we build a standalone from that loader stack, while still being able to edit the real stack. This made creating self-updating applications really easy before the days of sparkle and notirizaton. I remember shipping auto-updating applications on early MacOS X (and I bet people did it in classic).
As for XCMD they used to work but they don't anymore. Now, livecode has "livecode builder" language which is a low-level livecode-like language that allows you to do FFI, and you can still build "externals" which are native modules that you can call from livecode.
Well, now you just need to get a "livecode player" shipped in something widely distributed by default. :-D
The ability to cross compile is VERY cool, and I don't mean to belittle it or suggest that passing stack files around is better. As someone who builds software for distribution, the cross compilation is much better, and getting it done with compatibility that wide is technically really impressive.
But putting myself back in the headspace that had me using HyperCard, sharing my stuff without any build step at all was a big deal.
I like your loader stack technique. It sounds like just the sort of thing we'd have tried in HC if network access had been a common, reliable thing.
I'll take any opportunity to ask HN what sort of "Hypercard" like options are out there to get kids into programming. I still have many memories of creating my own "Choose Your Adventure" type game and having the other kids in my class be amazed at what I was able to create. It really stuck with me.
Scratch definitely gets the IDE aspect right: you can edit code, images, create and edit sounds, do layout, all in a sensible combined interface. Something like PySimpleGUI totally misses this point, and juggling different kinds of files will be too complicated for kids.
What Scratch doesn't get right is the card aspect. It's like Hypercard with one card, and the patterns involved in making basic shifts from one mode to another, or one level to another, involve lots of global messages and setup code. It's really bad. Making a Choose Your Own Adventure program will be very hard! It's my biggest disappointment.
https://arcade.makecode.com is quite nice, but is more "program" like than Scratch, where I think Hypercard is more "document" like than Scratch... and so MakeCode isn't exactly a move in the right direction. MakeCode is better for games, but not good for things that aren't games. Scratch is also natural for making videos (Flash-reminiscent), documents, silly music players, etc.
Also very fun is MakeCode Arcade, which makes it super easy create lo-fi sprite-based video games, which you can play in your browser or on a dedicated handheld console: https://arcade.makecode.com
Both work like Scratch, which is another great option. When I played with Scratch as a teenager, though, I remember being frustrated that it wasn't just designed to make programming easy, but also to "teach programming to kids"--which meant that it was easy to make games, but basically impossible to "take the training wheels off" and do more serious tasks, because there was no way to access the filesystem or the network or connect with any other software. That was almost ten years ago, so maybe this complaint is out of date--but it does get to what I like about the micro:bit, which is that it's super simple and fun to program, but still lets you make "real" things.
It's similar to Scratch (both use drag and drop "blocks", both use Smalltalk, although I think Scratch has a JS version now). The nice thing about EToys is that it manipulates objects in a direct and live way, whereas Scratch separate the "code" from the "scene". For example, EToys lets us draw a character and attach script blocks to make it move and react; but we can also attach script blocks to those script blocks; and so on. I find this more powerful, and reduces the barrier for "graduating" from block-based programming to "real" programming (EToys lets us mix and match scripting blocks with real Smalltalk code).
PICO-8 [1], a "fantasy video game console" might be good. It simulates something kinda like a C64, with Lua, tile and sound editors, etc. It's not as simple as Hypercard, but it comes with a number of examples and it's relatively easy to get something interesting moving around on the screen.
I'd probably say pygame which repl.it now has support for. It's pretty slick and works on a crappy school ChromeBook. For "regular" gui stuff I'd say PySimpleGUI (see my earlier comment above/below).
For CYA there are plenty of "interactive fiction" tools. They range in complexity from mere hyperlinking over simple state management to Turing complete programming.
This may sound crazy, but my 7 year old daughter and I had the most fun with TIC-80 (https://tic80.com) and Lua. She is very comfortable with the notion of writing a program that's later run, as well as the concept of variables. The only thing I wish TIC-80 had is an easy way to prompt user to input a string. This feature would be a game-changer for TIC-80 as a programming education platform.
For rapidly prototyping an idea, I have yet to find anything that was as good as VB6. Drag a button, write code. Want to change things about the button? Use properties, that live update the GUI without recompiling. It was so simple that a reasonably intelligent person could grasp it in an afternoon, but in the hands of a capable developer could do some very impressive things.
It was also a fun game to hunt for OCX controls that you could use in things that were downloaded or came on random disks or CDs.
I really feel like VB6 was the peak of that development model and we've been moving away from it since. And I get some of the reasons why (just look at the mess that comes from trying to do anything with Xcode storyboards and version control.) But for just rapidly trying out an idea, I have yet to find anything anywhere that was as good as VB6 was.
You can try Lazarus[0], which is essentially an open source Delphi, itself being a more "serious" alternative to classic VB using a real native compiler and more robust language (Object Pascal).
It is more complicated than VB6, though nothing that can't be figured out by playing around with it and the included examples (and IMO it has by far the best visual form designer - placing controls in a freeform way and then "tying" them together with anchors with padding, etc so that they resize properly feels much more intuitive than using layout managers like in other toolkits that emphasize more on making stuff with code and have WYSIWYG editors as an afterthought at best).
Sadly there isn't any open source tool that i know that approaches classic VB's simplicity (though when it comes to that i am a bit more of a VB4 fan - i think by the time VB5 was introduced, the UI got a bit too complicated for the "form editor with a scripting language attached" that classic VB was at its core).
To be completely honest I haven't been involved in the Windows ecosystem in probably 15 years so I am not really sure. I switched over to using Macs in 2005 or so. I just Googled it and poked around and, yeah, at a high level it looks a lot like the old VB form builder.
The thing is, the form builder was just part of what made the VB experience so great. It was how everything tied together conceptually into a complete environment that, crucially, was very easy to understand and very approachable. The form builder was easy to grasp, language was very simple and straightforward, and the documentation was just astounding (to this day I have yet to find anyone who has as good documentation as Microsoft did in the 90s.) You could crank out a simple app in a matter of hours with it.
In the late 90s I got swept up in the dot-com boom and started doing web development. That's been my primary bread and butter since, although these days I have moved into a more management-focused role so most of the development I do is on my own time to keep my skills sharp. I have occasionally written things in Java (using Netbeans, whose form builder was very similar to VB) and Objective-C (again, Interface Builder reminded me a lot of VB).
I've been doing a lot of Swift recently for macOS development because it's such a fun language, but I haven't jumped over to using SwiftUI. It's just not ready for prime time yet, IMHO, especially for macOS apps. And I really just prefer building GUIs using a GUI builder like Storyboards or even old fashioned NIBs/XIBs, since most of the macOS apps I write I am the sole developer on, the version control issues with GUI definition files aren't a big issue for me.
Though I will say that I think SwiftUI has potential - especially with the live preview as you're building. It just doesn't work very well right now for complex macOS apps.
From a glance, it looks like it has the better features from either of HyperCard: message passing between "objects" vs. the class hierarchy, and VisualBasic: timers vs. the idle message, floating properties box vs. the dialog box.
<snark>It would be good if it has an option/property for resizeable windows "stacks" with some of the auto-resizing, alignment, and guides like Xcode - maybe it does, I get an error every time I attempt to login to LiveCode. "Critical mass" in user communities would be the killer feature, too bad the LiveCode App doesn't come by default with every new iPhone.</snark>
Xojo is pretty slick, but 1) LiveCode crushes it in the forms design department, and 2) No Android support. They have been promising it since just after John Quincy Adams was elected, though it appears to be in beta.
Never mind that Livecode IDE runs on Linux, Mac and Windows it also can produce compiled apps that run on those 3 platforms and iOS and Androd and even as a webapp like PHP. And it can even compile to HTML5 (although that's more limited).
It works with version control and unicode, it has regex, cryptography, sockets, JSON, XML, OAuth2, SVG etc. It has database libraries for interacting with sqlite, postgresql, mysql, etc. It can incorporate a web browser and control that using Javascript and callbacks. It can be extended to integrate with Java, Objective-C, etc. You can create your own GUI widgets. And it's free.
But that's still too much like Hypercard, which only ran on an ancient Mac and nothing else. Hypercard could do about 10% of what Livecode can do. And Hypercard has been dead since before you touched an IDE.
HyperTalk and LiveCode aren't 100% compatible (probably around 80%, less if you used a lot of XCMDs since they aren't supported), but if you have an old stack you want to modernise, LiveCode is a great and affordable (it's GPLv3, with a commercial offering if you need to publish closed source projects) way to do it.
The best resource[1] on converting a HyperCard stack to LiveCode is by Jacqueline Landman Gay of HyperActive Software[2]. I believe HyperActive can also do consulting and conversion work for HyperCard stacks to LiveCode.
[1] https://www.hyperactivesw.com/mctutorial/rrintro.html
[2] https://www.hyperactivesw.com/index.html