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.
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.
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.
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?
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?
> 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?
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.
> Programmers don't make software that crashes for fun, you know.
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.
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 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 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.
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.