> 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.
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.