You prefer inexplicable crashes? Now these are enough to drive someone mad.

And if you do prefer them, wire your debugger to a Blue Screen of Death emulation.

I have also loaded up an OS and browser built on a cross-platform GUI framework and a TCP-IP stack, and used it to do a DNS lookup and send a HTTP compliant request across a tangle of hundreds of miles of interconnected systems to Google's servers to statistically analyse my query, run it through around 700 servers, through an index of several billion web pages, and thousands of years of Youtube videos, millions of pictures, hundreds of thousands of news articles and twitter streams, ranking the results, and at the top putting the results of my calculation "2+1" or whatever.

But then, I'm not the author with the weirdo view of 'simple'. What's your point?

If you're new to programming, "make a calculator" is a great project. It involves simple math -- which you probably already understand -- simple operations, and simple concepts.

It also illustrates some of HyperCard's strengths. I can't think of any other development environment in which "make a calculator" would be a suitable project for the end of the first week of a programming class. And, in the end, the programmer gets something that they can look at and interact with, and which can be easily extended. ("OK, now make it do factorials!")

> It's almost funny, until you read his seven tenets of computing and find that any program which encounters any error should enter a debugger, so you can fix it and carry on. I think that would drive anyone insane.

I wish it worked that way!

Yes, if programs were constantly crashing into debuggers, it would drive people nuts. Absolutely, no argument there. But, I would hope that that alone would motivate programmers to make them crash less.

What we have instead are mysterious black boxes, and I hate that. But, I'm on the end-user support side of things. Here, let me give you some examples of stuff we've dealt with in our little shop in just the last few days:

1. An iMac that hates booting. Sometimes it boots, sometimes it won't. We invoke "verbose" mood, we get some sort of helpful text, and then it all goes away to a black screen. Or, it decides, "OK, all done with verbose mode!", switches to a gray screen, and hangs. Or, we attempt an install from any of our sets of install DVDs, and the most helpful error message we can dig out of any log anywhere is, "i/o error in dvd-rom" (or something similar). It is literally impossible for us to pinpoint the source of the hardware trouble without shotgun replacing every one of the major components in the machine.

2. A FreeBSD system that occasionally does a hard hang. No error log, anywhere. At all. Just halts. Hardware problem? Software problem?

3. An Acer Aspire One with all kinds of really unhelpful error messages in the system logs. Everything seems to be glitching everywhere. Ah, but Windows 7 helpfully generated a mini-dump file of just one of the crashes. Maybe we can track down a bad driver? Let's see, we'll just find and install dumpchk.exe and ... hmm, need to fix debugger symbols for this and ... wait, there's no stack trace? ... uhm ... oh look, it has a "probable cause" at the bottom: "hardware". That's helpful?

I know I'm forgetting some. Anyway, it's like this for us all the time.

I used to know & love MacsBug. Even with the old MacOS programmer's switch, I could occasionally figure out something useful. I would love it if, instead of calls like, "my computer is stuck at a black screen, should I reboot?", we'd get calls like, "my computer just went to this black screen that says null pointer exception at a bunch of numbers in iaStor.sys".

And, even better, if we were so inclined, we could notify software vendors of the specific errors we ran across, so we could do a better job of helping them track down bugs.

Visual Basic 3?

What we have instead are mysterious black boxes, and I hate that. But, I'm on the end-user support side of things. Here, let me give you some examples of stuff we've dealt with in our little shop in just the last few days:

I don't need examples - I wrote my comment on a phone, and twice it popped up Input system error. The system is being restarted, which, it seems, is a spell-check problem. And that's a system which does me more annoyance than good even when it's working normally.

We have a firewall with a subsystem which crashes when enabled, and the manufacturer says it's a known problem with no estimated fix time, the only option is to disable that feature - one of their main selling points of the device.

A web server, showing problematic memory use and no process using it.

GVim on Windows 7 x64 - I could (not sure if I can remember what it was now) repeatedly make it hang, not just itself but also the entire OS, with an operation on a large file which is instant on Linux. Yet Task manager shows no high CPU or memory or disk use.

Anyway, it's like this for us all the time.

Yes, but it's a fallacy to think I could practically do anything about it if only it wasn't so black box like. Do you really have time and motivation to become expert enough in all the things you deal with that you could fix any problem if only it was more explorable?

You may as well ask a restaurant if you can watch the staff cook all your food over their shoulders so you can intercept and change things if you think it's going in a direction you don't want.

Even if you are able to taste too much sugar in an Apple Pie, it doesn't follow that you could remove the sugar if only you were in the kitchen watching how much was put in (it's dissolved by then), and it doesn't follow that you could tell if too much was put in just by looking - it depends on how sweet the apples are, and whether the sweetness changes with length of baking.

See also: the idea of systemantics.

And what am I going to do when it's your webserver crashing, or your iCloud server, or DropBox, or if it's my car navigation system or my phone's spell checker?

But, I would hope that that alone would motivate programmers to make them crash less.

Programmers don't make software that crashes for fun, you know. If it took no effort, they would make programs which don't crash right now. But it does take effort, and that's a limited resource which needs to be traded off.

Never used it, couldn't say. But, I did find some online tutorial type stuff for VB6: http://www.vb6.us/tutorials/little-more-advanced-hello-world...

I think we're going to get mired in semantics and splitting hairs. After all, "get name of me" doesn't objectively make any more sense than "lblHello.Caption". Still, I find HyperCard's interface much cleaner in general, and key phrases like "Private" and "Option Explicit" are to me huge red flags for a beginner language.

So, you're right that VB3 could be used for a "make a calculator" lesson in the first week of a programming class. But, so far, I think I'd rather do it in HyperCard.

I think it's a fallacy to say you'd need to become an expert in all the things you deal with to benefit from the openness; you just need one person to fix it and distribute the changes. How many users benefit from CyanogenMod due to Android's openness, despite having never touch the source?

Well, that's our job. And, I specifically gave examples of unexpected behavior, in the sense that these were things that shouldn't ordinarily be behaving this way. The examples I gave were of cases where it definitely would help to have better troubleshooting tools available.

> And what am I going to do when it's your webserver crashing, or your iCloud server, or DropBox, or if it's my car navigation system or my phone's spell checker?

Whatever it is that you do now?

> Programmers don't make software that crashes for fun, you know.

I didn't say otherwise. Not sure why you brought this up.

I guess I still don't understand why "crash to debugger" would be worse than current behavior.

I didn't say otherwise. Not sure why you brought this up.

You implied that this would motivate programmers to make software which doesn't crash, as if software which doesn't crash is pretty much a choice they could make but aren't making. I'm saying programmers are already trying to make software which doesn't crash and it's just not that easy - If a user seeing an error message isn't helping, how will the motivation of a user seeing a debugger change things?

I guess I still don't understand why "crash to debugger" would be worse than current behavior.

It would be worse in terms of user experience; I'm sceptical that it would help a tenth as much as it is implied it would help - crashes being so deep, so numerous, so subtle, and so often due to some interplay between "working" systems.

So, wait for a debugger to load, then close it again, would be the default action. And that would be annoying.

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 agree with what you're saying, broadly.

There is no contradiction between the two:

http://en.wikipedia.org/wiki/Elektronika_BK