Hypercard – Way Too Early
avc.com
avc.com
Also, why “way too early”? Too early for what?
The most important feature of HyperCard, in my opinion, was that it gave end-users powerful general-purpose tools for programming and solving their own problems, in a way that was easy to get started with. Instead of being locked into someone’s existing program designed with an idealized customer’s needs, any HyperCard user could create or customize a HyperCard stack to suit their own preferences.
Unfortunately, tools requiring customer learning and mastery are very difficult to design and implement, and even more difficult to demo and sell. And so our software is designed in a very narrow and limiting fashion. The “cards” in android and facebook and twitter &c. are doing nothing to combat this, and to compare them favorably to HyperCard is in my opinion to completely (and tragically) miss the point of HyperCard.
I don’t see any particular signs of this trend toward closed systems reversing; indeed, as more people come online, and giant corporations spend billions of dollars hiring all the smartest people to work on developing software that gives them (the corporations) as much control as possible over uses of computer hardware/software, the popular machines and software systems are only getting more closed and locked down. The web itself is an open and flexible platform, but increasingly people are spending their time in a few centralized and controlled parts of it.
HyperCard was probably one of the most influential pieces of software ever written. It still has one direct clone ("Livecode") being sold commercially, and I believe Director (whose programming language started as an inferior clone of HyperTalk) is still being sold by Adobe.
It was also an incredibly stable programming environment. Back in an era when computers in general were as flaky as hell, you could work on it all day and experience nary a crash (and since it saved everything by default you tended not to lose anything even when it did crash).
Remember that HyperCard was introduced in 1987 or so, the GUI/WIMP era was just getting started. The learning curve of writing a Macintosh application was incredibly steep - nearly impossible IMO - but here was a way to make a simple point-and-click app that actually did something (write to a file, do some calculations, show information, even talk out the serial port, etc) with a minimal amount of lifting. My first paid piece of software was a point-of-sale application written in HyperCard. And it worked just fine.
VB was pretty much the equivalent for Windows, once it came along.
The web is close in some respects (HTML is easy) and not in others (servers and single-page apps are not).
I suppose, in another respect, Excel is a successor for many, though it isn't a good solution for making apps of any sort.
Surprisingly, the closest I've seen has been Microsoft's Project Siena[1]. I've not used it extensively, but my 5 or 10 minute made it look like it had the dirt-simple-to-get-started appeal of HyperCard and VB.
Anyone know of other "spiritual successors" out there?
[1] http://apps.microsoft.com/windows/en-us/app/microsoft-projec...
I'm hoping Mozilla's AppMaker[3] comes to something, but I haven't been able to actually make it work yet.
I can't say that I find any of these really (yet) hitting the sweet spot that HyperCard did, but that may be my own ignorance. :-D
Apple's networking APIs weren't very well designed. In fact, you couldn't even get to AppleShare volumes; there wasn't an official API to mount 'em. So I wrote one, and I was still getting occasional email about the Mount XCMD a decade later. Apple just didn't have much vision or follow-through back in the late 80s and early 90s.
a) It was written quickly by one programmer (Bill Atkinson) who left Apple shortly after and (if rumors are believed) no one else really understood his code.
b) It never really adapted to colour displays
c) It never adapted to variable size displays
d) It had no networking so it couldn't compete with the web
e) It didn't run on Windows or Unix so it couldn't compete with the web
f) It was closed source and proprietary so it couldn't compete with the web
g) The free version of Hypercard was made read-only and lost the ability to write and edit stacks (taking away the entire point of Hypercard)
h) XCMDs were a pain to write but required for almost anything (Hypercard's API were never really extended to include new features as the Mac added them)
i) Apple themselves stopped using it for all help and tutorials on the Mac so people stopped experiencing its metaphors when they first used their Macs
j) Apple moved it to Claris (who killed everything they touched)
True from a market standpoint, I recall one of the Mac magazines had an article about jerry-rigging a database front-end in HyperCard, and it was clear it was no VB.
However, more similar in spirit to HyperCard was Lotus Notes, with its networked hypertext document databases where data storage was largely abstracted away. That was a proprietary web before there was the web. (However with an awful UI and ugly templates.)
Fortunately the company I was working for that used it had other "bad environment" issues (e.g., running awful antivirus software on dev machines, resulting in a 4X slowdown of compiles), and I ragequit to do coffee shops and bookstores for a summer.
Notes: both a symptom and a disease :-)
But like HC, the Notes designer software was turned into an added-cost product, and after that both Notes and HC became the domain of 'IT experts' that knew how to work around the limitations of a rinky-dink platform.
This was all long ago, for most people now Notes is just a terrible email application.
You are right about the level of IT capability of most small shops, maybe I "crippled" would have been better than "destroyed".
But elitist?
Have you ever considered working on your home furnace? There are people who can do these things. The ones who THINK they can do it are Darwin Award winners.
The downside of an amateur rolling their own solution in Notes was not life threatening but it certainly wasn't smart.
Notes gave people who had no idea what they were doing the confidence to build solutions that were fine for personal use but completely unsustainable at even small office scale.
The "experts" who adopted HC and Notes were the ones who did the real damage though. These folks (and I knew a few) were just a step above the guy in the office who refilled the toner in the photocopier. They created half-working systems and then moved on. They didn't have to live with the technical debt they left in their wake.
They set unrealistic expectations for what good IT solutions should cost and left guys like me trying to clean up their mess for years.
In any case, Notes ended up sucking, anyone who saw what happened can toast to that.
Some suggestions. First, if you've typed longer than a minute, make a backup copy of your reply, even go so far as to compose it in a separate text editor, then paste the result into HN. Second, if you encounter the dreaded "link expired" message, select all (Ctrl+A) then copy (Ctrl+C) the content of the entry window, then press browser refresh, then paste (Ctrl+V) the text you just copied. Then click "Reply."
(Trick question, R3 only had ctrl-insert etc OS/2 shortcuts!)
In any case I apologize my paste-buffer foibles denied you my three paragraphs of immense wisdom regarding the good & bad of an obsolete end-user friendly distributed database system that went out of style a couple decades ago.
Lowest common denominator, as they say. When I encounter someone who loses his content on the HN interface, I make some simplifying assumptions. :)
In 1994, when I was in fifth grade, I used HyperCard to make a demo of a program that would allow you to fax a grocery order to a store using a modem after you checked off the items you wanted to buy. Then the store would deliver your order to you. I didn't actually know how to make use of hardware devices like modems, but it was possible to make the user interface work reasonably well on a Macintosh LC II. I was of course bummed that there was no color. (HyperCard was black and white only unless you used proprietary extensions, which could sometimes make things run very slowly.)
The author of this post seems to think that HyperCard was "before its time," but it wasn't. It defined its time, and ours. It was a huge part of what made the Mac so appealing to so many people--the ability to sculpt new technology in a custom manner. There was no comparably easy-to-use tool on the PC--Visual Basic didn't come close--and there never would be. The result was that all kinds of Mac owners developed their own stacks that solved exactly whatever problem they thought needed solving; PC owners had to hope that a software company would make something for them.
What's sad is that now our computers are so much faster than the LC II I used in fifth grade, but even if they're a hundred times faster, they're certainly not a hundred times easier to develop for. Most fifth graders, even smart ones, probably couldn't write an app in Objective-C that does today the same things a HyperCard stack did in 1994. HTML5 is the next best option, but it's still not as easy.
I worked on a prototype of a modern-era web-based HyperCard with a friend, but we stopped working on it because there was no VC interest and it wasn't clear if there would be a good business model. It's a shame, because HyperCard is one of the things that most excited me about computers when I was a kid. I still miss it.
If Apple were run with a different mindset, they might turn XCode into HyperCard again. If Google were run with a different mindset and Android were something other than Java, you might see them build their own HyperCard-style development environment instead of relying on the abomination that is Eclipse.
I think people would—its biggest strength is that tons of people could make their own "apps" using it, and I don't think that ability will ever become obsolete.
The very earliest mobile web app standard, HDML (later WML), used a deck-of-cards metaphor. This was around the mid-90s.
"The fundamental building block of HDML content is the card. The user agent displays and allows the user to interact with cards of information. Logically, a user navigates through a series of HDML cards, reviews the contents of each, enters requested information, makes choices, and moves on to another or returns to a previously visited card." - HDML spec [1]
I'm not sure what Fred Wilson is getting at with "cards" today (he seems to be lamenting restricted APIs more than anything with the UI paradigm?). But in the HDML era they served a specific purpose: decks could be downloaded over high-latency networks in one shot and navigated offline, instead of waiting for each "page" to load.
[1] http://en.wikipedia.org/wiki/Handheld_Device_Markup_Language
In the browser the presentation, runtime and persistence layers (otherwise known as DOM, JavaScript and the web/LocalStorage) are completely separate. So, you need loads of code to bootstrap your particular version of editable web that HyperCard gave you for free, without any save buttons, serialization protocols or web server and database installs. This seems so basic thing, yet it's so hard to get there in the modern browser. Forms have in their own, peculiar data structure completely unusable for all but simple cases without a clever encoding system and JS data binding. Rich text editing is so unreliable across implementations that you need to get a library like CodeMirror to turn textarea into transformation pipeline simulating the process of input. Saddest part is that the priorities of developers are elsewhere, in building the browser into best consuming platform and a fastest tool to send little snippets of text to social network silos.
One of these days I might turn LigthTable into the past version of HyperCard, with the future build in. Since it comes with a browser, server and the JVM there should be more than enough code to replicate functionality of few megabytes of 68000 assembler ;)
It is an IDE to build small visual Mac apps. A card is basically an app.
Less than that. Must have been 512x342; as I remember using it on 9" Mac Plus and Classic BW screens?
That doesn't mean the author built something like Myst, though.
Meanwhile, before Hypercard, there is a notable product: Guide by OWL in Scotland, who were approached by Tim Berners-Lee as his desired candidate for the world wide web. Matsushita had then in an 80s Japanese shopping frenzy bought up OWL (lawyers on the same trip to Scotland went on to buy a couple of distilleries and golf courses in the same week). Japanese management of OWL then turned down Berners-Lee.
Maybe it was just bad technology or a bad implementation.
If it was really that good (it wasn't) then it would have survived. The fact that nothing of any consequence works this way today is telling.
You could only go so far with HyperCard before running into limitations and that's deadly.
It was easy for beginners but offered no advantage to experts. Once you graduated beyond HyperCard you could never go back.
Market death.
I don't think VB killed Hypercard. Apple never got color, networking, etc. working and put no effort into it. Hypercard would have died with or without VB.
I did a lot of stuff with Hypercard back in the day and it's such a ridiculous statement that I ended up writing the guy off completely. He was real big on generated code and full of BS in general.
A design style? Individual screens rather than a scrolling document?