One reality of software development (or anything development, really) is that a product will only be as good as the customer demands it should be. Our economic system drives manufacturers to produce what the customer wants, and not much more.
So, if we all expect that our windows software is going to crash fairly often, when it does, we aren't surprised, and we don't demand better. (And how could we, Often times there's no way to tell it had anything to do with the software in question) On Mac OS X, we don't expect crashes so much, and when the software we are working in crashes, we view it as bad software quality, but some of us remember OS 9 enough to excuse it for the most part. For linux and (insert Unix-OS here) we expect our server apps to be reliable, and when they are not, we look for alternatives. When our Linux desktops crash, we chalk it up to beta software or whatever... but still it's an abnormality... but we forgive, after all, it's a volunteer project (most of the time.)
The crash-resistance of software increases proportionally with our expectations. Simple economics, really. Supply and demand, if we demand stable software more than whiz-bang software, we are going to get it. The majority of people don't. They expect computers to act that way. They are still 'technology' after all. People expect new technology to be problematic. We won't put up with half the problems on our home phones (not 'technology' in most peoples minds) that we put up with on our cell phones.
As someone else pointed out. NASA and The U.S. Navy do not run on unstable systems. The systems they run on have different levels of reliability because if they didn't, they would have bought something else in the first place.
Regarding languages and the quality of the code different languages produce, there is no correspondence.
A programmer who understands both the syntax and the programmatic idioms of, say, C, can produce code that is just as unlikely to crash as another programmer who has the same level of ability and experience with, say, java.
All to often people think that because they know the syntax of the language well they know how to program in the language well. This is simply not the case. There is much more to programming than being able to write code. A programmer who understands the idioms of the language, and uses them them during the design phase (yes there is a whole phase where you just think about how to solve the problem) tends to produce higher-quality code than someone who does not.
For example, if you understand pointers and you know how to safely use them, they will not cause you problems in your code. If you are not diligent about managing your pointers, you will have problems. If you don't know to use bounded string operations, you can have buffer overruns, is that the languages fault? no.
The complexity of systems is bunk too. Yes, systems are more complex. However, as long as interfaces are well defined, and the developer follows the rules of the api, you will not have problems. Once again, there are more than syntactic rules here. For example, the Cocoa APIs on Mac OS X (and gnustep) have very well-defined rules about who 'owns' objects. It is very easy to ignore these and produce working code. If you do, though, you will have problems with object leakage in your programs at best, and outright crashes at worst.
(yes,there can be bugs in system libs, but they occurs less often than bugs in joe developers code, in my experience, and are usually fixed more quickly.)
In short, I think there is no technical reason that applications and computers crash. The 'bad software' problem lies mainly with people, what they will accept and won't accept, and programmers who believe that because they can write a program in a language they know the language. There's a big difference between the two.
Slashdot Mirror
One reality of software development (or anything development, really) is that a product will only be as good as the customer demands it should be. Our economic system drives manufacturers to produce what the customer wants, and not much more.
So, if we all expect that our windows software is going to crash fairly often, when it does, we aren't surprised, and we don't demand better. (And how could we, Often times there's no way to tell it had anything to do with the software in question) On Mac OS X, we don't expect crashes so much, and when the software we are working in crashes, we view it as bad software quality, but some of us remember OS 9 enough to excuse it for the most part. For linux and (insert Unix-OS here) we expect our server apps to be reliable, and when they are not, we look for alternatives. When our Linux desktops crash, we chalk it up to beta software or whatever... but still it's an abnormality... but we forgive, after all, it's a volunteer project (most of the time.)
The crash-resistance of software increases proportionally with our expectations. Simple economics, really. Supply and demand, if we demand stable software more than whiz-bang software, we are going to get it. The majority of people don't. They expect computers to act that way. They are still 'technology' after all. People expect new technology to be problematic. We won't put up with half the problems on our home phones (not 'technology' in most peoples minds) that we put up with on our cell phones.
As someone else pointed out. NASA and The U.S. Navy do not run on unstable systems. The systems they run on have different levels of reliability because if they didn't, they would have bought something else in the first place.
Regarding languages and the quality of the code different languages produce, there is no correspondence.
A programmer who understands both the syntax and the programmatic idioms of, say, C, can produce code that is just as unlikely to crash as another programmer who has the same level of ability and experience with, say, java.
All to often people think that because they know the syntax of the language well they know how to program in the language well. This is simply not the case. There is much more to programming than being able to write code. A programmer who understands the idioms of the language, and uses them them during the design phase (yes there is a whole phase where you just think about how to solve the problem) tends to produce higher-quality code than someone who does not.
For example, if you understand pointers and you know how to safely use them, they will not cause you problems in your code. If you are not diligent about managing your pointers, you will have problems. If you don't know to use bounded string operations, you can have buffer overruns, is that the languages fault? no.
The complexity of systems is bunk too. Yes, systems are more complex. However, as long as interfaces are well defined, and the developer follows the rules of the api, you will not have problems. Once again, there are more than syntactic rules here. For example, the Cocoa APIs on Mac OS X (and gnustep) have very well-defined rules about who 'owns' objects. It is very easy to ignore these and produce working code. If you do, though, you will have problems with object leakage in your programs at best, and outright crashes at worst.
(yes,there can be bugs in system libs, but they occurs less often than bugs in joe developers code, in my experience, and are usually fixed more quickly.)
In short, I think there is no technical reason that applications and computers crash. The 'bad software' problem lies mainly with people, what they will accept and won't accept, and programmers who believe that because they can write a program in a language they know the language. There's a big difference between the two.