Why Hypercard Had to Die

It's funny you mention a personal wiki. I think the first thing I used Hypercard for was to create a catalog of my comic book collection.

(All of the work that went into it was lost due to an accident, which taught me a hard lesson about the need for backups.)

No, I said crash less. I completely avoid any debates about "perfect" software, they're pointless.

Maybe I misunderstood you. When you said, "I think that would drive anyone insane", I assumed that for some reason we were talking about a greater quantity of crashes. (Might've been the "any program ... any error" bit beforehand.)

Here, let's assume we're stuck with two options, and for both options, we'll assume that the initial rate of crashes is the same:

1. Program crashes. There is an unhelpful error message, or no error message, or it hangs. User reports the error, or doesn't, and reboots.

2. Program crashes. Debugger immediately loads. User can contact support, or not. Support may receive actually useful information about the cause of the error. User reboots.

I don't really see why the debugger scenario is worse in terms of user experience, and I'm a loud and vocal advocate for improving UX. To me, it's clear that there are strong benefits and no additional drawbacks to having a drop-to-debugger policy for broken software, because even if an end user can't do anything with it, we might be able to, and even if we can't, the end user is no worse off. You specifically say "wait for a debugger to load", but I remember MacsBug being pretty darn snappy. I can't think of a reason why it would be necessary to wait for one to load, certainly to wait any longer than you have to wait for an unhelpful error message as it is.

And, if dropping to a debugger was really a terrible, terrible thing, then yes, I think application developers would put more effort into preventing it. I don't expect software to magically become flawless, but we run into plenty of errors that appear to be caused by a programmer making an effort vs. reward tradeoff in favor of letting the bug go.

I mean, you and I both gave examples of frustrating software problems without even trying hard. There are countless others. Either these problems are an inevitable and unavoidable consequence of complex systems, as you seem to be saying, or they are examples of people putting in less effort than they could. If it's the former, we are well and truly fucked, because software is only getting more complicated, not less. If it's the latter, then I don't think it's fair to argue against efforts to make software crash less. You can't have it both ways.

Anyway, I think we're getting sidetracked, and this little discussion isn't fixing any bugs. Suffice to say, I don't think that mocking the author for daring to suggest that programs should error-drop into a debugger is a very powerful criticism. I for one would really appreciate it if they did that, so I guess I'm as nuts as he is.

I had a sudden hypothesis after reading this thread last night. (No proof, mind you, just an idea.) I wonder if HyperCard's success was for the same reason as UNIX's success: a well-chosen, small set of interoperable tools that allowed the user to do far more than the sum of their parts. And, as computing and interfaces have become more complex, we've just tacked on complexity to them rather than reinventing them to adapt.

For instance, UNIX's treatment of everything as a file is a great tool, but I think there was a time where that simplified a much greater percentage of computing than it would today. Similarly, I suspect HyperCard died because the abstractions it was using had to be reimagined to stay competitive.

Spreadsheets (as mentioned elsewhere) are an example of a product that has managed to stay focused on the simple set of tools, and, when features were tacked on, they often stay out of the way instead of adding complexity to day-to-day operations. However, I'm not sure they've aged well, but I guess they are the best we have at the moment.

I was only mocking the author for wanting both ubiquitous debugging as a top-7 must have conputing feature, while at the same time decrying complexity and pining for a simple system.

I agree with what you're saying, broadly.

HyperCard like systems are not dead. I make my living from LiveCode ( http://www.runrev.com ) which is a xTalk system that is able to build applications for Mac OS X, Windows, Linux, iOS and Android. From a single HyperCard-like environment, I can build apps for all these platforms and reuse the code.

LiveCode is very verbose and it may take a while for those that are already familiar with C-like languages but it is worth it. Software is easy to maintain and there is little space for confusion, even with few comments.

RunRev company also release a PHP-like engine, so I can create web applications that communicate with native clients on mobile and desktop all from a single language and environment, this is very powerful.

You should always use the best tool for your job. For my job, LiveCode fits perfectly. I also think that xTalk languages are a wonderful introduction to programming and people from non-technical backgrounds can learn it easily and start creating little tools to help their specific domains. Yes, anyone can learn programming in any language, it is just a matter of effort, I believe LiveCode makes this effort fun and productive.

You may read this as advertisement but this is my personal opinion. I am 31 and have been using LiveCode since I was 25 or something like that. In the meantime I got married, got my own place and am living a good life. All my work is LiveCode related. Just telling you that so you guys don't take me for "someone that toys with this cute language every once in a while but is not serious".

Even if you already have your favorite language, it is worth to check out LiveCode, just to learn what else is out there. There are beginner webinars starting next month I think...