An amusing error: whenever I try to read a particular email, Mail crashes. The mail in question? A post-purchase Apple store survey, highlighted above.
As opposed to those expected crashes. Programmers really need to stop coding in a stateful imperative style, and start programming in a persistentdeclarative style -- for fault tolerance (such as how TCP/IP was designed).
In other words, software should expect that parts of it will crash and it should automatically recover and reconstitute itself without the user noticing. If your application has to throw a dialog window, you've failed. (c.f. the iChat "lost network connection" message the user must acknowledge; just auto-reconnect you stupid software!)
My favorite example is photoshop, which pops up screen-freezing "click me" error messages to inform you that what you just tried to do coudn't be done -- and closing it chain-opens another one just like it to detail some irrelevant explanatory fact about the original message.
My favorite example is photoshop, which pops up screen-freezing "click me" error messages to inform you that what you just tried to do coudn't be done -- and closing it chain-opens another one just like it to detail some irrelevant explanatory fact about the original message.
That reminds me of another annoyance: error messages that only say that "System Error code -1052" has occurred, and then you have to go look up somewhere what that error actually means, instead of, you know, including that error message when the error is actually thrown.
error messages that only say that "System Error code -1052" has occurred, and then you have to go look up somewhere what that error actually means, instead of, you know, including that error message when the error is actually thrown.
Which is up there at the top of the idiocy rankings along with web sites that can detect when pop-up window blockers are used and then load an error page to complain (asking the user to disable pop-up blocking), instead of actually designing the website to simply not use pop-up windows in the first place.
The window quicktime pops up to tell me I need to upgrade to the newest version crashes my firefox every time.
What makes it particularly frustrating is that I end up needed to update quicktime just to stop the "you need to update" notifier from crashing firefox. So I end up doing exactly what they want me to do, because not doing it will cause *their notifier* to crash my browser.
Proper error catching is one of the most fundamental concepts in software engineering, and yet it always seems to be overlooked. I understand that current software environments are very complex and interconnected. Thus, any software that can throw an understandable error message and then keep running is a top piece of code in my books.
I absolutely agree with other posters griping about numbered, unexplained error messages. That #@$% drives me up the wall.
What makes it particularly frustrating is that I end up needed to update quicktime just to stop the "you need to update" notifier from crashing firefox. So I end up doing exactly what they want me to do, because not doing it will cause *their notifier* to crash my browser.
What's frustrating here is that software needs to update automatically and reversibly (if you don't like the changes) while never having to reboot or reload your data in the application.
The entire "Software Update" dialog is unnecessary. The operating system should never have to reboot because you updated Quicktime or even the Kernel. The persistent data store should just be read by the new code while the old code gets put in storage. We don't have this yet because in stateful imperative programming the valuable user data is stored inside the application's memory, and if the application crashes the user's precious data goes with it -- the baby with the bathwater.
Importing and exporting data into and out of an application is also why we have the cognitive hassle of "Open" and "Save as" (damn you Ken Thompson!), instead of simply looking at an "open buffer" handle as, say, EMACS does (or Multics did). With persistent data, everything is an "open buffer".
I've been using PCs my entire life and last december finally heard my colleagues and bought a MacBook white.
This kind of crash keeps happening all the time. I don't use Mail because I can't even configure it to work with my corporate Microsoft Exchange account. But that happens with Pages and Firefox. In fact, the last post on the Twitter I've set up to tell about changing from PC to Mac is about it: http://twitter.com/itjustworks
What's funny is every macmaniac kept telling me that Macs don't crash. I guess it's an effect of Jobs' distortion field to overlook contraditory data.
What's funny is every macmaniac kept telling me that Macs don't crash. I guess it's an effect of Jobs' distortion field to overlook contraditory data.
They didn't, until 10.5 "Leopard". I figure it's because Leopard was released prematurely because it was already late after resources were diverted to release the iPhone (which was also missing some obvious features to get it out the door in time).
I also come to suspect that OS X benefited at first from a "clean slate" beginning, and slowly adding hardware and software support. As complexity grows, so do the places for bugs to hide. How long can "OS Ten" evolve in the random pressures of an ecosystem before it starts to converge on Windows? I hope by then Apple will release "OS Eleven".
What's funny is every macmaniac kept telling me that Macs don't crash.
Actually, unless you know a whole gang of delusional idiots, you've never been told that. You've also never been told that "Macs are totally immune to haxx0rz!" Nor have you ever been told "OS X can't ever get a virus because [password]."
You don't need to make shit up to have valid critiques.
It is damn hard to take down the Mac operating system. Taking down an individual application however, is not at all uncommon. The same is true for WinXP. I've seen neither an OS X kernel panic screen nor the XP equivalent in a few years.
As opposed to those expected crashes. Programmers really need to stop coding in a stateful imperative style, and start programming in a persistent declarative style -- for fault tolerance (such as how TCP/IP was designed).
In other words, software should expect that parts of it will crash and it should automatically recover and reconstitute itself without the user noticing. If your application has to throw a dialog window, you've failed. (c.f. the iChat "lost network connection" message the user must acknowledge; just auto-reconnect you stupid software!)
My favorite example is photoshop, which pops up screen-freezing "click me" error messages to inform you that what you just tried to do coudn't be done -- and closing it chain-opens another one just like it to detail some irrelevant explanatory fact about the original message.
The same thing happens to me on a very specific e-mail from my father.
It's the only one that I've found to do this. Odd, huh?
I saw this post in my feedreader and I thought my Mail had quit. Clicked on the image. Yup.
The window quicktime pops up to tell me I need to upgrade to the newest version crashes my firefox every time.
What makes it particularly frustrating is that I end up needed to update quicktime just to stop the "you need to update" notifier from crashing firefox. So I end up doing exactly what they want me to do, because not doing it will cause *their notifier* to crash my browser.
Proper error catching is one of the most fundamental concepts in software engineering, and yet it always seems to be overlooked. I understand that current software environments are very complex and interconnected. Thus, any software that can throw an understandable error message and then keep running is a top piece of code in my books.
I absolutely agree with other posters griping about numbered, unexplained error messages. That #@$% drives me up the wall.
The entire "Software Update" dialog is unnecessary. The operating system should never have to reboot because you updated Quicktime or even the Kernel. The persistent data store should just be read by the new code while the old code gets put in storage. We don't have this yet because in stateful imperative programming the valuable user data is stored inside the application's memory, and if the application crashes the user's precious data goes with it -- the baby with the bathwater.
Importing and exporting data into and out of an application is also why we have the cognitive hassle of "Open" and "Save as" (damn you Ken Thompson!), instead of simply looking at an "open buffer" handle as, say, EMACS does (or Multics did). With persistent data, everything is an "open buffer".
I've been using PCs my entire life and last december finally heard my colleagues and bought a MacBook white.
This kind of crash keeps happening all the time. I don't use Mail because I can't even configure it to work with my corporate Microsoft Exchange account. But that happens with Pages and Firefox. In fact, the last post on the Twitter I've set up to tell about changing from PC to Mac is about it: http://twitter.com/itjustworks
What's funny is every macmaniac kept telling me that Macs don't crash. I guess it's an effect of Jobs' distortion field to overlook contraditory data.
I also come to suspect that OS X benefited at first from a "clean slate" beginning, and slowly adding hardware and software support. As complexity grows, so do the places for bugs to hide. How long can "OS Ten" evolve in the random pressures of an ecosystem before it starts to converge on Windows? I hope by then Apple will release "OS Eleven".
What's funny is every macmaniac kept telling me that Macs don't crash.
Actually, unless you know a whole gang of delusional idiots, you've never been told that. You've also never been told that "Macs are totally immune to haxx0rz!" Nor have you ever been told "OS X can't ever get a virus because [password]."
You don't need to make shit up to have valid critiques.
It is damn hard to take down the Mac operating system. Taking down an individual application however, is not at all uncommon. The same is true for WinXP. I've seen neither an OS X kernel panic screen nor the XP equivalent in a few years.
Largely it comes down to how one defines "crash."