Communications of the ACM

BLOG@CACM

The Role of Hypercard in Today's World

By Mark Guzdial
April 30, 2013
Comments (5)

I loved HyperCard, the end-user programming environment that came free with every Apple Macintosh from 1987 through 1998.  My dissertation work focused on high school students who learned physics by building simulations in HyperCard.  I have heard that Apple estimated that one out of every three Macintosh users built something in HyperCard, which suggests that over a million people tried programming in HyperCard in pre-Web days.

HyperCard was quirky and weird.  There were objects (like buttons and text fields) and inheritance, but you couldn't define new classes so it wasn't really object-oriented.  Hypertalk, the programming language within HyperCard, was wordy and unusual.  Valid statements included put zero into counter and add one to counter and repeat for each word x in field 1...end repeat  and if field "name" begins with "Mr." then...end if.

HyperCard never really went away.  Commercial spin-offs of HyperCard for different operating systems have continued, still featuring HyperCard's odd object structure and unusual HyperTalk language. Probably the most successful of these is LiveCode. After a Kickstarter campaign, LiveCode has just released an open-source version which runs on Mac OS X, Windows, and Linux and can produce iOS and Android apps.  HyperCard runs again, on modern machines.  

So what do we do with it?  We live in a Web 2.0 world, where we have an Internet of Things and many of those things are programmmable. Does HyperCard and HyperTalk still have a place?

The CEO of Livecode, Kevin Miller argues in his blog post "Six Reasons Why Computer Science Education is Failing Students" that LiveCode fills in the gap between graphical programming languages and traditional textual languages.  Primary and secondary school omputer science education around the world is dominated by tools like Scratch and Alice.  Professional programming languages (like Java, C++, and JavaScript) are textual and use more powerful computational mechanisms.  LiveCode (and tools like it) could fill in the gap, as a readable and English-like textual language to access more powerful computation.

I suspect that the real challenge that Hypercard faces in today's world is a perception that it's not solving an important problem.  It's a long-standing challenge. In an insightful 1985 article in Annals of the History of Computing, Ben Shneiderman asked about "The Relationship between COBOL and Computer Science."  Why didn't academic computer scientists take COBOL seriously?  Shneiderman write, "I suspect this prejudice [against COBOL] emerges from the bias of many computer scientists against the problem domain and the wordy, nonmathematical style of COBOL, rather than from any serious consideration of the technical weaknesses."  COBOL aimed to make business data processing more accessible to a broader range of people.  That wasn't an important goal to those Shneiderman interviewed.  The critiques of COBOL that Shneiderman quotes could just as easily have been about HyperTalk: "folly of an English-looking language."

We can still see a pushback against making programming more accessible.  A May 2012 blog post that was quoted widely begs, "Please Don't Learn to Code." Several comments to my blog post in response talked about the terrible code that novices write, and how they make more problems for professional programmers. Computer users are still seen mostly as consumers, and not creators of code.

I find the critique of COBOL's "English-looking language" and the many references I found on HyperTalk's "wordiness" fascinating because our empirical evidence says that the wordiness works.  Wordy languages are better for novices and experts alike.  Thomas Green and his colleagues found in 1977 (Sime, Arblaster, & Green) that conditionals in the form "if P; do A; not P; do B; end P" are easier for novices and experts to use, and novices corrected mistakes in their programs ten times faster with the wordy versions than the traditional "if P then do A else do B."  Research on how non-programmers specified tasks found that specifying iteration like repeat for each word x is much easier and more natural for novices.

In the most recent Communications of the ACM, I have an article about our Human-Centered Computing PhD here at Georgia Tech.  I argue that our modern computing environment is "Licklider's World." It's the world that J.C.R. Licklider's vision created.  Notably, Licklider was not a mathematician nor an electrical engineer.  Most of his degrees were in psychology.

COBOL was ahead of the game, in thinking about the end-user first, and it was rejected by academic computer science.  The challenge for LiveCode and other successors to HyperCard is to face the same prejuidice that Shneiderman described.  We may not recognize the features of programming languages that work to make programming more accessible, because they are not necessarily the features that professional or academic computer scientists most value.  We need to draw on Licklider's psychology and empirical evidence, because end-user programmers and secondary school computing students are not like those who use professional languages.  If we want to make programming accessible to them, we have to study them, not use introspection or design for ourselves.

---

Comments

---

Displaying all 5 comments