Comment by mcguire | Hacker News Reader

Comment by mcguire | Hacker News Reader

Parent Full thread

"It was an incredibly open-ended piece of software, allowing those without much expertise in programming (or even any at all) to build a wide variety of computational tools. To borrow a formulation from Seymour Papert (who co-created the programming language Logo), HyperCard had low floors and high ceilings."

Speaking as someone who used HyperCard to create a couple of applications, this is...somewhat overstated. It was quite good at creating things that resembled flipping through a deck of cards. (One app was a "smart test" that would present a more-or-less difficult question based on the user's previous answers---my first introduction to Bayesian statistics.)

It was, however, not a good programming environment if you needed to do anything complex---think of writing a complicated Emacs major mode, not using Emacs lisp but a simplified textual language intended for those without much expertise.

This is a general problem for systems built for "those without much expertise in programming (or even any at all)"; they may be able to do simple things, but you'll still need to be a "real programmer" to do slightly more complicated things, and a "real programmer" will be doing it with one hand tied behind their back.

While I never used HyperCard, the ‘low floors and high ceilings’ makes me think of spreadsheets. Given that I code all day professionally, I have quite a high bar for using code to solve personal needs, but I love to use spreadsheets - there’s just enough automation to make powerful, useful mini-applications, quickly, without much complexity, and the presentation capabilities are very strong. While there is brittleness - I can share a budget sheet with my wife and it will be broken in minutes - it’s easy to fix and evolve, but most importantly, they are accessible and grokable for someone without much technical knowledge.

I guess spreadsheet apps are pretty self-contained so I’m not sure that composability is a strength.

I think of HyperCard as sort of a domain-specific language for a certain UX.

If your application was naturally modeled as a set of records and where you wanted a nice UI to navigate and edit records, it was incredibly easy and productive to get up and running. It's hard to understate how much easier it was to make a GUI app for storing recipes or something along those lines in HyperCard compared to anything out there.

But, like other domain-specific languages, if your app didn't fit that UI style, it got real weird real fast and you felt like you were swimming upstream.

Funny thing is that exactly that last bit is how it lured me into CS. A bit of friction is an excellent motivator.

> think of writing a complicated Emacs major mode, not using Emacs lisp but a simplified textual language intended for those without much expertise.

That's good enough to build form-based apps with basic conditional logic, which was Hypercard's biggest use case.

A person can sit through a Hypercard tutorial and learn how to build a small app using forms. That same person will have a much harder time rebuilding that app in PHP or Xamarin.

> It was, however, not a good programming environment if you needed to do anything complex

I liked that they had an escape hatch, though. If you wanted to do complicated things and had the skill to do so, you could write an XCMD or XFCN in C or Pascal and which could be called from your Hypercard stack. Not a perfect system, but useful and extensible.

I'm rather biased, but I think HyperTalk was mostly a mistake. A well-written HyperTalk script can be clear for a novice to read and (hopefully) modify, but this comes at the cost of making it an intensely longwinded, fiddly, and ambiguous language to program with and to implement. The focus on text manipulation as the primary "data handling" paradigm is very convenient for some problems, but the lack of proper lists and associative structures is a liability for complex programs.

Nevertheless, HyperCard on the whole was still enough to be highly empowering to a very broad userbase, which cannot be understated. It is difficult to quantify the amount of productivity and enjoyment that can be given to users simply by allowing them to make minor changes to personal software themselves, even if the bulk of the work was done by some "real programmer".

As someone who tried to use HyperCard and, after much lost time, went back to more traditional programming tools, I agree with your assessment. The idea behind HyperCard was neat, but HyperCard itself made it easy to write simple programs with lots of cute window dressing, and impossible to write complex ones.

I used HC extensively, both by itself and with code resources that I wrote in Pascal or C. I certainly pushed it way beyond its capabilities, by using the parse-able pieces of text strings as crude data structures. What unreadable code I wrote. But HC was a great way to write small but useable programs for people.

I switched to Visual Basic when it came out. VB did a lot of what HC could do, plus it had more traditional structures, and was more than grudgingly supported.

As someone who also used Hypercard, I tend to agree. There's a reason we aren't still talking about Hypercard today the way it was talked about then, but it was a different time. We were so much more enamored with software's potential. Today, we get upset if a button press takes five seconds instead of one.

Reply on news.ycombinator.com