The Best Programming Language Ever?

I was having a conversation at work today about what people’s tastes in programming languages were and there was some discussion about human readability, which led me to mention HyperTalk. HyperTalk was the programming language used by HyperCard, it had the virtue of being incredibly readable and (unlike the similarly readable AppleScript) also very easy to write. I mentioned that “whenever you see — used to denote a comment, there lies the ghost of HyperTalk” to which someone replied, “like in HTML?”.

An HTML comment is denoted by “<!–” and “–>” (note that WordPress is screwing this up, I really do know what HTML comments look like) which seems like a non-coincidence. Tim Berners Lee invented HTTP and HTML using NeXT computers, which didn’t run HyperCard, but which were spiritually related to the Mac, and it’s hard to imagine that HyperCard wasn’t a major influence on the design of the web.

HyperCard has the distinction of being one of the most influential programs ever written, perhaps the most. (Bill Atkinson wrote HyperCard and MacPaint, two of the most influential programs ever written. Photoshop is, essentially, MacPaint running on modern hardware.) Paul Allen spent a fortune cloning it (Toolbook) and it was clearly a huge influence on Visual Basic. Director’s Lingo started out as a straight clone of HyperTalk. Even 3D Studio Max’s MaxScript bears its mark. If we assume that the web was directly inspired by HyperCard — a not unreasonable assumption — that makes it perhaps the most influential ┬áprogram ever written.

HyperCard was amazingly nice to code in. HyperCard 2 had a modern debugger, there was a third party compiler (written in HyperTalk that could compile to assembler), and it virtually never crashed. By default, all state was preserved (in fact, if you wanted to write a conventional application you had to jump through hoops to create “empty” documents). The main failing of HyperTalk was its lack of support for OO and functional programming (it was internally an object-oriented message-passing architecture, but you couldn’t build your own objects). It would be pretty simple to bolt that kind of functionality onto it, but no-one has, and HyperTalk has largely passed into obscurity.

Surprisingly, there are three modern HyperCard clones still being maintained. Toolbook has focused on authoring CBT, while Runtime Revolution tries to be all things to all people, and SuperCard is Mac only. Unfortunately, all seem pretty clunky by today’s standards. (And, frankly, for all its virtues, HyperCard was a bit clunky even when it was new. It never allowed you to build proper user interfaces.)

It would be interesting to see HyperTalk updated to support modern language features OR something like HyperCard built on top of a modern language like Python or Ruby. The obvious thing to do would be to build a web-based IDE on top of Django or Rails.

  • Andrew

    I never thought much of Hypercard the language – really the brilliance was the execution environment, but also its prison.

    eg Bill got the metaphor working for cards, but never quite managed dialog boxes, or as you point out, anything resembling how regular programs worked.

    In a spare minute or two I’m experimenting with some similar concepts, or at least with the ability to author an application incrementally while ‘live’ (though as it will be allowing direct access to Cocoa, it will presumably be eminently crashable).

    ie Hypercard gained a lot of its stability by sandboxing the code within an inch of its life.

  • HyperCard had a lot of obvious deficiencies which in true “Apple under Sculley” fashion (awesome 1.0 release, late 2.0 release which ignores obvious problems, no 3.0 release — see Apple Media Tool, Newton Messagepad, QuickTake, etc.) were never addressed. E.g. it provided absolutely no programmatic support for handling any medium other than text, and initially no support for color followed (eventually) by incredibly lame support for media and color.*

    But none of these things were intrinsic flaws in the concept (they were, according to legend, problems with the codebase — but someone at Apple was able to release HyperCard for the IIgs with pretty much all of this stuff fixed in almost no time at all, so it seems to me that the issues were political and not technical).

    Things like “persistent by default” could easily have been fixed (and certainly weren’t hard to fix yourself).

    Why is sandboxing code within an inch of its life a bad thing?

    It always seemed to me that the Newton would have been successful if it ran an extended HyperCard/HyperTalk instead of NewtonScript et al. Similarly, AppleScript would have been more successful had they simply extended HyperTalk in some obvious way rather than come up with AppleScript’s incomprehensible “read only” syntax.

    * Even so, I remember building a mockup of a multimedia project we were developing in Visual Basic 3.0 under Windows in HyperCard in 1994, and the HyperCard version on a 25MHz 68040 with 20MB of RAM ran circles around the VB version running on a 66MHz PC with 64MB of RAM.

  • Andrew

    Sandboxing isn’t such a bad thing, but it immediately establishes whether you are in the sand box or not.

    The big cost of sandboxes is just how big a bucket of tools you will be provided, as typically safer versions of the OS routines need to be crafted to be suitable for the sandbox – either to:
    * perform additional validation
    * dumb them down
    * make them play by the rules of the sandbox with regards to things like callback mechanisms

    Putting aside that most of this is a grim indictment of how horrible OS routines are (well at least they don’t tend to bring down the entire computer any more), it does represent a cost of sandbox construction.

    Java probably provides the most complete sandbox out there, albeit at the cost of not really integrating with any operating system particularly well above the POSIX layer. ie it tends to be a joke for any UI stuff, though this is more of a function of its attempted broadness.

    Hypercard gave you a pretty minimal sandbox – you pretty well had to resort to XCMDs and XFCNs if you wanted to do anything interesting whatsoever.

    RealBASIC also provides a sandbox, and a substantially more capable one than Hypercard (albeit less stable) – though at a much greater cost.

    Of course the other problem is that you then have to go and document the new API you’ve provided in your sandbox, defend why you dropped this particular parameter, etc.

    Which isn’t to say that sandboxing doesn’t provide a strong advantage: i.e. to help insulate the user from the horrors that regular developers face on a daily basis, it’s just that there are strong disadvantages too

  • Truls

    Oh my, does HyperCard bring back memories. I discovered this amazing piece of software from a demo floppy for System 7. This was sort of an interactive presentation created in HyperCard, giving quite a good feel of what the next generation OS was like. I since spent many nights hunting for cool stacks created by others, and playing around with HyperTalk.

    Did you know the original version of Cyan’s legendary game Myst was created in HyperCard?

  • Yes — in fact Cyan released several HyperCard-based games culminating in MYST (I bought one of their earlier games, a kids’ game loosely inspired by Alice in Wonderland).