> bugs exist. deal with it. expecting anything less is naive.
That's exactly the attitude that baffles me. Sure bugs exist... but why not eliminate the ones that are easy to eliminate?
Especially something as déclassé as a buffer overflow in "secure" networking infrastructure?
> to rewriting these in 'safe' languages. thank you very much but no.
The issue I wanted to raise isn't a suggestion for a re-write, but rather, why wasn't it done right in the first place? This could have been prevented easily, either by choice of language or use of alternative I/O routines.
> pushing the responsibity for security off the software author and onto the compiler/virtual machine is not a solution. it just deflects blame.
That's a curious excuse^w attitude.
> not to mention the performance implications of doing crypto in a virtual machine. blech
I certainly didn't have Java in mind. There are plenty of ways of avoiding this problem without resort to a virtual machine.
> Thanks to "many eyes," no sooner is a flaw detected than it is patched up!
<pedantic>Actually, "many eyes" didn't have much to do with either facet, this time. The detection was done by the (presumably pay-to-view) eyes at A.L. Digital Ltd and The Bunker, and the fix isn't an "eyes" issue at all, but rather a get-on-the-ball-and-do-it issue.</pedantic>
But you're entirely right about the quick turn-around. The good folk at OpenSSH completely skipped the Six Step Security Patch Development Cycle so commonly used in the commercial software world thes days:
deny it, as long as possible
promise an investigation, as long as possible
promise "real soon now", as long as possible
make excuses for the delay, as long as possible
release a broken fix, investing as little effort as possible
> 1. The client master key in SSL2 could be oversized and overrun a buffer.
> 2. The session ID supplied to a client in SSL3 could be oversized and overrun a buffer.
Forgive me for opening the language flamewars again, but doesn't anyone else find this "a wee bit inexcusable" in software designed for secure network access?
As has been mentioned here countless times before, there are languages that disallow buffer overflows (period), and for people who don't want to use those languages there are libraries that replace built-in I/O functions for the same effect.
Hasn't it occured to anyone in the security industry that buffer overflows are a serious threat, and for things like SSL, BO-proof coding should be adopted as a matter of policy, rather than as a bug-to-fix-when-we-catch-it?
I'm not trying to villify anyone, and I'm really glad to see that someone has been hired to do a thorough security audit... but I just find this kind of thing completely incomprehensible, when it's so easy to avoid it in the first place.
> In an attempt to figure out how statistically significant the article's 6-in-a-million chance of the asteroid hitting earth is, exactly, I ran a search on the most popular statistic--the odds of being hit by lightning.
A few years ago Scientific American had a really interesting article on the risks of various things happening and the disconnect between the actual risk and the perceived (intuitive) risk. They had a scale which, IIRC, spanned two pages, and marked where lots of familiar and exotic was of kicking the bucket fell on that scale.
The funny thing was that their baseline was a 1/1,000,000 chance - the risk you run by living off peanut butter sandwiches for a month.
> truly insignificant threats to individuals get hyped all out of proportion routinely, at least in this case it was an insignificant threat to the entire planet.
Which happens to be entirely relevant. Suppose activity A poses you with a 1/100 chance of losing a dollar and activity B poses you a 1/100 chance of losing $100,000. Are they equivalent risks? In terms of raw probability, yes. In terms of the expected value of their cost to you, no - B poses a threat five orders of magnitude higher than A.
For planet-buster asteroids we need to look at the expected value of the cost to our species, not at the raw probabilities. I.e., this is much, much less likely than having another solar flare disrupt our communication systems, but if it does happen it will hurt us far, far more than a mere communication disruption.
> > They have always demonstrated sanity, restraint and professionalism along with thoughtful commentary - unlike certain other well known Linux news sites. Very sad.
> I'm surprised this not-so-veiled insult made it onto the front page...
Proving that the editors not only don't read the stories, they don't even read the screedle that introduces the stories.
> they could cut the bandwidth usage here at least in half by using stylesheets
Excuse me, could someone tell me which style I'm supposed to use for "first post" attempts? Also for "flamebait" posts, though of course I need the "first post" style right away.
> BTW,it's theoretically proven that security provided by Discretory Access Control systems (in which ACL's and unix protection schemes belong to) is algoritmically unprovable - you cannot deduct that system is secure based on system and DAC rules.
Thanks, I'd never heard that. Do you know whether government security certification levels take that into account?
ACLs (access control lists) are a wonderful technology, but for non-trivial systems they become an administrative pain in the @ss. In principle you would set them up and forget about them, or at least let users maintain their own, but in practice users can't maintain their own, and they will pester you to death with requests for changes.
They also tend to drag the sysadmin into office politics. E.g., Secretary A is out on vacation and Secretary B calls you and says Secretary A did not set up her ACLs correctly and would you please give B access to certain of A's files. In addition to the annoyance of having to babysit the users, there's really no correct response to such a request.
ACLs would be great on a system where everyone is a power user. In practice that usually means your home system where you are the only user, so ACLs aren't very helpful anyway.
Conclusion: wonderful technology, hope I never see it again.
BTW, I speak from personal experience, having formerly managed VAXen with their wonderful ACL implementation. I don't object to ACLs on Linux, I just don't want them.
> If you're frightened like some little girl about if the changes are legal, that's really not up for you to decide directly anyway.
Wipe the foam off your lip and re-read my post. I didn't comment on the legality or even the desirability of the changes; I merely suggested that people look behind the rhetoric of terror and see why public officials say these things.
And in case you haven't noticed, the Administration is having a bit of trouble selling some of their agenda to the public.
> And do you really think a liberal in office would have done much different?
Did I say, hint, suggest, or imply that I thought any such thing?
Truth to tell, I think that Bush has been the puppet of political necessity since 9/11 (and on the stock market issue, too), so that if we had Gore instead of Bush we would have been seeing the same moves and hearing the same bullshit that we've been seening/hearding from Bush. Probably the only big difference would be an absense of the "Get Iraq!" talk (which, BTW, appears to be driven primarily by W's daddy's cronies rather than by W himself).
> So now you guys in the US have someone in the government that is fighting windmills.
Remember, this guy is now part of an Administration that follows a policy of using the threat of foreign terrorism to terrorize the public into accepting legislation, policy changes, and major reorganization of government agencies. The key for reading this guy, just as for the rest of them, is to look beyond the FUD and see what his agenda is.
> Unfortunately your experience is far too common I have experience teaching Ada and C++ and was always amazed at the things people found to not like about Ada.
Me too, though I'm not sure I mean the same thing as you did when you wrote that.
Side note, the Ada old-timers often wryly point out that the reasons they often hear people give now for liking newer languages such as Java are often the same reasons people gave for not liking Ada 20 years ago.
> When using Ada I was often suprised at the level of frustration caused when a reasonably intellegent person is forced to jump through a lot of hoops in order to get a piece of code to compile.
Actually, that's exactly why I think Ada should be used as an introductory language. If beginners would learn to say what they mean and mean what they say, the world would be full of better programmers. If it takes a surly compiler to enforce a bit of discipline on beginners, then I'm all for it.
The software crisis isn't a result of having trouble getting programs to compile; it's the result of the attitude that anyone who can get something to compile is a programmer. We need to raise the bar on that somewhat.
> I place less value on minimizing keystrokes than I do on being able to do something without having to figure out all the conversions necessary to get it done. Call it a weakness or whatever, but I find I like a weakly typed language like Perl for this reason.
I'm less of a hard-liner than I may sound sometimes. E.g., for quick hacks I almost always use Scheme. (I wouldn't call it "weakly typed", but it is declaration-free.)
> Of course, it may very well be that using Perl is like going over to the dark side...I don't know. I do know that after a year and a half programming nothing but Perl that it was really tough to do C, let alone sit down with Java or Ada.
I think any language can have that effect. After a year when I used an extra lot of Scheme, I found myself asking "Where's the $CENSORED in-line 'if' function?!?!?" when I went back to my my work-a-day habits.
> However, my two biggest gripes with Ada are its typecasting and its I/O routines because you can't mix types.
There's a pretty easy workaround for mixed I/O in Ada; you just append all the garbage together into a single string argument. It will still have something rather like the typecasting where you convert all the numerics/whatevers to their string images, but at least you don't have to do a separate Put for each item.
> Perhaps I'm settling for the 'Laziness' virtue here, but I wonder if it's unreasonable to expect that sort of ease of use in other languages.
"Ease of use" is always a problematic concept. While Ada is too syntax-heavy for many people's tastes, I find that after suitable declarations I can often program at a very high level of abstraction. (Though perhaps that's true of any language?)
At any rate, in line with what another poster said yesterday, I shudder to imagine doing some of the stuff I have done recently if working in some of the other languages I've used in the past. For me, "ease of use" has to be a big-picture evaluation. Which is, I suppose, why I use Scheme for a quick math problem and Ada for 10,000 line program.
> Ada is more like a construction worker's toolbelt. You have lots of little safety devices attached to keep you from maiming yourself, but it also precludes you from doing create or clever work.
Good analogy.
Thing is, we expect creativity and cleverness from architects, but not from construction workers. Construction workers are supposed to follow well established procedures that contribute to cost-effective construction of a correctly built structure. When a construction worker decides to express his creativity by welding a joint that is spec'd out to be bolted, or leave out a few bolts in the name of speed or weight reduction, then he's off the job.
And even the architects have a lot of constraints placed on how they can express their creativity and cleverness.
> When even simple typecasting is a chore, then a language qualifies as anal.
I'm not denying that it helps to be anal if you program in Ada. What I'm arguing is that our profession needs to be more anal about things than we traditionally have been.
As for typecasting, I like to think of it as a way of telling the compiler, "Yes, I know what I'm doing, and yes, I really did intend to do it."
The goal, for some of us, is to minimize bugs rather than minimizing keystrokes.
> Windows 2000 is certainly more reliable than Windows NT, but in different situations you can be rebooting daily. My opinion is that it depends on what you are doing, and it depends on what hardware you run.... An example of a low-uptime Windows app is an application server or power-user workstation.
Alas, I happen to be particularly interested in stability for power-user workstations.
> Let me be the first (or second or third) to point out that TeX, quite possibly the world's only bug free program, is written in Pascal, an ancestor of Ada.
Let me add that in the typical programming team of n programmers, you can expect to find about 0.00000n Donald Knuth's. Erich's pointing out that TeX works very well is about as useful as pointing out that Einstein was right about relativity. Most of us don't operate in Knuth's league any more than we do Einstein's, and so we need all the help compiler technology can give us.
> You act as though C is responsible for a stack overflow or pointer pointing problems.
> You wanna know something: IT'S THE PROGRAMMER.
Yep, people write programs. And the errors are almost always the people's fault, not the language's. And people can, in principle, write correct code in any language - including by toggling the machine code in on the front panel.
But you're missing the point. The reason we don't toggle our programs in on the front panel is that it is very error prone, and we can eliminate a huge number of errors by putting the computer itself to work doing that sort of tedious grunt work where lots of errors occur.
And that's why some of us use Ada instead of C. It's essentially the same reason we prefer C to assembly language and prefer assembly language to toggling in the machine code. Programming is fun; tracking down stupid bugs isn't. The question isn't which language prevents you from writing buggy code; the question is which one helps you catch the most bugs with the least effort. Let the compiler do the grunt work.
And which do you think has the least negative economic impact: catching a bug when you compile, catching a bug during testing, or catching a bug in a system that's already in production?
If your language can move bugs forward in that process, it can save your company money. (And perhaps even save lives.)
You are entirely correct when you say that people cause bugs. But that's an argument that supports the adoption of bug-reduction technology, not an argument against adopting it.
> Let me tell you a little story.... Once the garbage collector had finished, the arm was allowed to move, but by that time it was too late.
FYI, there are many different GC algorithms, including some that make trade-offs to ensure that the GC never uses more than a fixed amount of time. If someone uses a language with an inappropriate GC algorithm in a real-time situation, you should take that as de facto evidence that they aren't qualified for the job.
> Macros in C are the most useful thing about the language, in my opinion. Not having them is a horrible travesty.
Bet you never saw a bug that resulted from using a macro, either.
The first step in solving the world's software crisis must be owning up to the distinction between "what I like" and "what's good for me".
> I thought all this "proven correctness" stuff was laid to rest when the "proven correct" software examples in Dijkstra's seminal book on the subject proved to have at least four bugs.
I haven't heard that particular story, but proofs certainly haven't been laid to rest by that or anything else.
> It is not possible to prove that software is "correct". That is because what constitutes "correct" varies with the intent of the software.
Yes, formal proofs require formal specs. (IMO the mere fact of pinning down the spec that carefully will probably do as much good as the verification proofs would.)
But the challenges of constructing formal proofs are irrelevant to the claim that algorithmic systems are inherently unstable. The fact that you can prove correctness for some algorithms is sufficient to refute that claim.
> Didn't catch the part where I said this: "It would have been up longer except I had to shut the box down to move it." Didja?
Yes, I did catch it. And it's completely irrelevant to my observation about how revealing it is for someone to bother mentioning a 3 mo uptime as evidence for an operating system's robustness.
> I have no idea how long the uptime would be if we didn't geographically move it.
Indeed you don't. And per your.sig, one example isn't very useful anyway. A more interesting measure would be MTBF, the standard deviation on that, and perhaps some suggestion of the upper bound (e.g., what's the MTBF for the 5% of machines with the best MTBFs).
But so long as you're mentioning uptimes that are a small fraction of the time some of us leave a source file open in the editor, or less than the amount of CPU time a developing program consumes during a test run without crashing, you're not going to score much of a PR coup.
As I said before, the biggest problem with software reliability these days is the low expectations on the part of consumers.
> It sure beats the pants off of "herrr herr, Windows crashes every 10 minutes." duddn't it?
I don't doubt that recent offerings from Microsoft are more reliable than Windows 2.0. Of course, you can make anything look good if you use a low enough standard for comparison.
For that matter, I still don't know the proper capitalization for Fortran ("formula translator" --> "ForTran"?) and Cobol ("common business-oriented language" --> "CoBOL"?).
Slashdot Mirror
> My point: the way C code is written, as well as the C language itself, makes doing 100% solid bounds checking basically impossible.
If true, that sounds like sufficient reason to avoid using C when writing secure networking software.
> bugs exist. deal with it. expecting anything less is naive.
That's exactly the attitude that baffles me. Sure bugs exist... but why not eliminate the ones that are easy to eliminate?
Especially something as déclassé as a buffer overflow in "secure" networking infrastructure?
> to rewriting these in 'safe' languages. thank you very much but no.
The issue I wanted to raise isn't a suggestion for a re-write, but rather, why wasn't it done right in the first place? This could have been prevented easily, either by choice of language or use of alternative I/O routines.
> pushing the responsibity for security off the software author and onto the compiler/virtual machine is not a solution. it just deflects blame.
That's a curious excuse^w attitude.
> not to mention the performance implications of doing crypto in a virtual machine. blech
I certainly didn't have Java in mind. There are plenty of ways of avoiding this problem without resort to a virtual machine.
> Thanks to "many eyes," no sooner is a flaw detected than it is patched up!
<pedantic>Actually, "many eyes" didn't have much to do with either facet, this time. The detection was done by the (presumably pay-to-view) eyes at A.L. Digital Ltd and The Bunker, and the fix isn't an "eyes" issue at all, but rather a get-on-the-ball-and-do-it issue.</pedantic>
But you're entirely right about the quick turn-around. The good folk at OpenSSH completely skipped the Six Step Security Patch Development Cycle so commonly used in the commercial software world thes days:
> 1. The client master key in SSL2 could be oversized and overrun a buffer.
> 2. The session ID supplied to a client in SSL3 could be oversized and overrun a buffer.
Forgive me for opening the language flamewars again, but doesn't anyone else find this "a wee bit inexcusable" in software designed for secure network access?
As has been mentioned here countless times before, there are languages that disallow buffer overflows (period), and for people who don't want to use those languages there are libraries that replace built-in I/O functions for the same effect.
Hasn't it occured to anyone in the security industry that buffer overflows are a serious threat, and for things like SSL, BO-proof coding should be adopted as a matter of policy, rather than as a bug-to-fix-when-we-catch-it?
I'm not trying to villify anyone, and I'm really glad to see that someone has been hired to do a thorough security audit... but I just find this kind of thing completely incomprehensible, when it's so easy to avoid it in the first place.
> In an attempt to figure out how statistically significant the article's 6-in-a-million chance of the asteroid hitting earth is, exactly, I ran a search on the most popular statistic--the odds of being hit by lightning.
A few years ago Scientific American had a really interesting article on the risks of various things happening and the disconnect between the actual risk and the perceived (intuitive) risk. They had a scale which, IIRC, spanned two pages, and marked where lots of familiar and exotic was of kicking the bucket fell on that scale.
The funny thing was that their baseline was a 1/1,000,000 chance - the risk you run by living off peanut butter sandwiches for a month.
> truly insignificant threats to individuals get hyped all out of proportion routinely, at least in this case it was an insignificant threat to the entire planet.
Which happens to be entirely relevant. Suppose activity A poses you with a 1/100 chance of losing a dollar and activity B poses you a 1/100 chance of losing $100,000. Are they equivalent risks? In terms of raw probability, yes. In terms of the expected value of their cost to you, no - B poses a threat five orders of magnitude higher than A.
For planet-buster asteroids we need to look at the expected value of the cost to our species, not at the raw probabilities. I.e., this is much, much less likely than having another solar flare disrupt our communication systems, but if it does happen it will hurt us far, far more than a mere communication disruption.
> > They have always demonstrated sanity, restraint and professionalism along with thoughtful commentary - unlike certain other well known Linux news sites. Very sad.
> I'm surprised this not-so-veiled insult made it onto the front page...
Proving that the editors not only don't read the stories, they don't even read the screedle that introduces the stories.
> they could cut the bandwidth usage here at least in half by using stylesheets
Excuse me, could someone tell me which style I'm supposed to use for "first post" attempts? Also for "flamebait" posts, though of course I need the "first post" style right away.
> BTW,it's theoretically proven that security provided by Discretory Access Control systems (in which ACL's and unix protection schemes belong to) is algoritmically unprovable - you cannot deduct that system is secure based on system and DAC rules.
Thanks, I'd never heard that. Do you know whether government security certification levels take that into account?
ACLs (access control lists) are a wonderful technology, but for non-trivial systems they become an administrative pain in the @ss. In principle you would set them up and forget about them, or at least let users maintain their own, but in practice users can't maintain their own, and they will pester you to death with requests for changes.
They also tend to drag the sysadmin into office politics. E.g., Secretary A is out on vacation and Secretary B calls you and says Secretary A did not set up her ACLs correctly and would you please give B access to certain of A's files. In addition to the annoyance of having to babysit the users, there's really no correct response to such a request.
ACLs would be great on a system where everyone is a power user. In practice that usually means your home system where you are the only user, so ACLs aren't very helpful anyway.
Conclusion: wonderful technology, hope I never see it again.
BTW, I speak from personal experience, having formerly managed VAXen with their wonderful ACL implementation. I don't object to ACLs on Linux, I just don't want them.
> If you're frightened like some little girl about if the changes are legal, that's really not up for you to decide directly anyway.
Wipe the foam off your lip and re-read my post. I didn't comment on the legality or even the desirability of the changes; I merely suggested that people look behind the rhetoric of terror and see why public officials say these things.
And in case you haven't noticed, the Administration is having a bit of trouble selling some of their agenda to the public.
> And do you really think a liberal in office would have done much different?
Did I say, hint, suggest, or imply that I thought any such thing?
Truth to tell, I think that Bush has been the puppet of political necessity since 9/11 (and on the stock market issue, too), so that if we had Gore instead of Bush we would have been seeing the same moves and hearing the same bullshit that we've been seening/hearding from Bush. Probably the only big difference would be an absense of the "Get Iraq!" talk (which, BTW, appears to be driven primarily by W's daddy's cronies rather than by W himself).
> So now you guys in the US have someone in the government that is fighting windmills.
Remember, this guy is now part of an Administration that follows a policy of using the threat of foreign terrorism to terrorize the public into accepting legislation, policy changes, and major reorganization of government agencies. The key for reading this guy, just as for the rest of them, is to look beyond the FUD and see what his agenda is.
> Unfortunately your experience is far too common I have experience teaching Ada and C++ and was always amazed at the things people found to not like about Ada.
Me too, though I'm not sure I mean the same thing as you did when you wrote that.
Side note, the Ada old-timers often wryly point out that the reasons they often hear people give now for liking newer languages such as Java are often the same reasons people gave for not liking Ada 20 years ago.
> When using Ada I was often suprised at the level of frustration caused when a reasonably intellegent person is forced to jump through a lot of hoops in order to get a piece of code to compile.
Actually, that's exactly why I think Ada should be used as an introductory language. If beginners would learn to say what they mean and mean what they say, the world would be full of better programmers. If it takes a surly compiler to enforce a bit of discipline on beginners, then I'm all for it.
The software crisis isn't a result of having trouble getting programs to compile; it's the result of the attitude that anyone who can get something to compile is a programmer. We need to raise the bar on that somewhat.
> I place less value on minimizing keystrokes than I do on being able to do something without having to figure out all the conversions necessary to get it done. Call it a weakness or whatever, but I find I like a weakly typed language like Perl for this reason.
I'm less of a hard-liner than I may sound sometimes. E.g., for quick hacks I almost always use Scheme. (I wouldn't call it "weakly typed", but it is declaration-free.)
> Of course, it may very well be that using Perl is like going over to the dark side...I don't know. I do know that after a year and a half programming nothing but Perl that it was really tough to do C, let alone sit down with Java or Ada.
I think any language can have that effect. After a year when I used an extra lot of Scheme, I found myself asking "Where's the $CENSORED in-line 'if' function?!?!?" when I went back to my my work-a-day habits.
> However, my two biggest gripes with Ada are its typecasting and its I/O routines because you can't mix types.
There's a pretty easy workaround for mixed I/O in Ada; you just append all the garbage together into a single string argument. It will still have something rather like the typecasting where you convert all the numerics/whatevers to their string images, but at least you don't have to do a separate Put for each item.
> Perhaps I'm settling for the 'Laziness' virtue here, but I wonder if it's unreasonable to expect that sort of ease of use in other languages.
"Ease of use" is always a problematic concept. While Ada is too syntax-heavy for many people's tastes, I find that after suitable declarations I can often program at a very high level of abstraction. (Though perhaps that's true of any language?)
At any rate, in line with what another poster said yesterday, I shudder to imagine doing some of the stuff I have done recently if working in some of the other languages I've used in the past. For me, "ease of use" has to be a big-picture evaluation. Which is, I suppose, why I use Scheme for a quick math problem and Ada for 10,000 line program.
> Ada is more like a construction worker's toolbelt. You have lots of little safety devices attached to keep you from maiming yourself, but it also precludes you from doing create or clever work.
Good analogy.
Thing is, we expect creativity and cleverness from architects, but not from construction workers. Construction workers are supposed to follow well established procedures that contribute to cost-effective construction of a correctly built structure. When a construction worker decides to express his creativity by welding a joint that is spec'd out to be bolted, or leave out a few bolts in the name of speed or weight reduction, then he's off the job.
And even the architects have a lot of constraints placed on how they can express their creativity and cleverness.
> When even simple typecasting is a chore, then a language qualifies as anal.
I'm not denying that it helps to be anal if you program in Ada. What I'm arguing is that our profession needs to be more anal about things than we traditionally have been.
As for typecasting, I like to think of it as a way of telling the compiler, "Yes, I know what I'm doing, and yes, I really did intend to do it."
The goal, for some of us, is to minimize bugs rather than minimizing keystrokes.
> Windows 2000 is certainly more reliable than Windows NT, but in different situations you can be rebooting daily. My opinion is that it depends on what you are doing, and it depends on what hardware you run. ... An example of a low-uptime Windows app is an application server or power-user workstation.
Alas, I happen to be particularly interested in stability for power-user workstations.
BTW, thanks for the balanced post on the topic.
> Let me be the first (or second or third) to point out that TeX, quite possibly the world's only bug free program, is written in Pascal, an ancestor of Ada.
Let me add that in the typical programming team of n programmers, you can expect to find about 0.00000n Donald Knuth's. Erich's pointing out that TeX works very well is about as useful as pointing out that Einstein was right about relativity. Most of us don't operate in Knuth's league any more than we do Einstein's, and so we need all the help compiler technology can give us.
> You act as though C is responsible for a stack overflow or pointer pointing problems.
... Once the garbage collector had finished, the arm was allowed to move, but by that time it was too late.
> You wanna know something: IT'S THE PROGRAMMER.
Yep, people write programs. And the errors are almost always the people's fault, not the language's. And people can, in principle, write correct code in any language - including by toggling the machine code in on the front panel.
But you're missing the point. The reason we don't toggle our programs in on the front panel is that it is very error prone, and we can eliminate a huge number of errors by putting the computer itself to work doing that sort of tedious grunt work where lots of errors occur.
And that's why some of us use Ada instead of C. It's essentially the same reason we prefer C to assembly language and prefer assembly language to toggling in the machine code. Programming is fun; tracking down stupid bugs isn't. The question isn't which language prevents you from writing buggy code; the question is which one helps you catch the most bugs with the least effort. Let the compiler do the grunt work.
And which do you think has the least negative economic impact: catching a bug when you compile, catching a bug during testing, or catching a bug in a system that's already in production?
If your language can move bugs forward in that process, it can save your company money. (And perhaps even save lives.)
You are entirely correct when you say that people cause bugs. But that's an argument that supports the adoption of bug-reduction technology, not an argument against adopting it.
> Let me tell you a little story.
FYI, there are many different GC algorithms, including some that make trade-offs to ensure that the GC never uses more than a fixed amount of time. If someone uses a language with an inappropriate GC algorithm in a real-time situation, you should take that as de facto evidence that they aren't qualified for the job.
> Macros in C are the most useful thing about the language, in my opinion. Not having them is a horrible travesty.
Bet you never saw a bug that resulted from using a macro, either.
The first step in solving the world's software crisis must be owning up to the distinction between "what I like" and "what's good for me".
> I thought all this "proven correctness" stuff was laid to rest when the "proven correct" software examples in Dijkstra's seminal book on the subject proved to have at least four bugs.
I haven't heard that particular story, but proofs certainly haven't been laid to rest by that or anything else.
> It is not possible to prove that software is "correct". That is because what constitutes "correct" varies with the intent of the software.
Yes, formal proofs require formal specs. (IMO the mere fact of pinning down the spec that carefully will probably do as much good as the verification proofs would.)
But the challenges of constructing formal proofs are irrelevant to the claim that algorithmic systems are inherently unstable. The fact that you can prove correctness for some algorithms is sufficient to refute that claim.
> Hey, someone had to bring it up. Boy, do I date myself by saying I had a structured software design textbook. :-)
I always lie and say I read it on the bathroom wall.
> Also, since most software cannot be returned for refund, even if ridiculously defective...
And of course, even if you could take it back for a refund, you'd just get another copy of the same thing.
The actual choice is almost always between crappy software and no software, which is why people so avidly consume the crappy stuff.
> Didn't catch the part where I said this: "It would have been up longer except I had to shut the box down to move it." Didja?
.sig, one example isn't very useful anyway. A more interesting measure would be MTBF, the standard deviation on that, and perhaps some suggestion of the upper bound (e.g., what's the MTBF for the 5% of machines with the best MTBFs).
Yes, I did catch it. And it's completely irrelevant to my observation about how revealing it is for someone to bother mentioning a 3 mo uptime as evidence for an operating system's robustness.
> I have no idea how long the uptime would be if we didn't geographically move it.
Indeed you don't. And per your
But so long as you're mentioning uptimes that are a small fraction of the time some of us leave a source file open in the editor, or less than the amount of CPU time a developing program consumes during a test run without crashing, you're not going to score much of a PR coup.
As I said before, the biggest problem with software reliability these days is the low expectations on the part of consumers.
> It sure beats the pants off of "herrr herr, Windows crashes every 10 minutes." duddn't it?
I don't doubt that recent offerings from Microsoft are more reliable than Windows 2.0. Of course, you can make anything look good if you use a low enough standard for comparison.
> We've also got an NT4 webserver running IIS, and it's been up for 3 months.
Most telling of all is the fact that you think 3 months of uptime is worth mentioning.
For some of us, once in three months is excessively frequent for logging out, to say nothing of rebooting.
> Thanks for the heads up. My mistake. :)
No problem; it's a common mistake.
For that matter, I still don't know the proper capitalization for Fortran ("formula translator" --> "ForTran"?) and Cobol ("common business-oriented language" --> "CoBOL"?).
No one is born knowing these things.
> I thought it was a re-used software module, not hardware.
It has truly been a long time in dog years since I read it, so you might want to look it up rather than take my word for it.
But as you say, the distinction is irrelevant to the discussion at hand. There is no expectation that an Ada compiler will catch design errors.