3 ms·

>why is it that C is so much more often poorly programmed than, say, Python? It's kind of like saying: trauma surgeons must be more dangerous than pediatricia

by xamuel 12y ago

>why is it that C is so much more often poorly programmed than, say, Python? It's kind of like saying: trauma surgeons must be more dangerous than pediatricians, because so many more patients die in the care of a trauma surgeon than in the care of a pediatrician. It ignores the fact that you wouldn't send a pediatrician to such a difficult patient as you'd send a trauma surgeon to. You wouldn't use Python in a lot of the places you'd use C because the performance would be "shaggy puppy meets Godzilla" lousy. >That's not the only alternative Suppose I've established that the fastest way the computer can do X involves having the CPU (which only knows machine code, no magical languages) access a memory location without checking if it's in bounds. Either the language allows me to program that, or it doesn't. If it does, then Heartbleed-like bugs are possible. QED. Alright, there's technically one other alternative, require the programmer to formally proof-verify that the code does as it's supposed to. I hope that this will become more practical within my daughter's lifetime (it probably won't within mine).

copsarebastards 12y ago
> It's kind of like saying: trauma surgeons must be more dangerous than pediatricians, because so many more patients die in the care of a trauma surgeon than in the care of a pediatrician. It ignores the fact that you wouldn't send a pediatrician to such a difficult patient as you'd send a trauma surgeon to. You wouldn't use Python in a lot of the places you'd use C because the performance would be "shaggy puppy meets Godzilla" lousy. You can make any argument by analogy. > Suppose I've established that the fastest way the computer can do X involves having the CPU (which only knows machine code, no magical languages) access a memory location without checking if it's in bounds. Either the language allows me to program that, or it doesn't. If it does, then Heartbleed-like bugs are possible. QED. Suppose we don't suppose things that are wrong. Static type checking can check bounds at no runtime cost this in many cases. Like I said, your argument is based on ignorance of the alternatives. > Alright, there's technically one other alternative, require the programmer to formally proof-verify that the code does as it's supposed to. I hope that this will become more practical within my daughter's lifetime (it probably won't within mine). I'm not hoping for 100% formal verification here, I'm merely hoping to be significantly better than C. That's a very low bar: C does very little checking. Why on earth would you be opposed to this? In fact, I don't think we'll ever be able to 100% formally verify that a program does what it's supposed to. You can verify some things, like memory access, but in the end we'll never be able to 100% verify that the thing we are verifying is the desired behavior. Look, I'm not criticizing the people who made C or the people who wrote tons of code in C. C was a great language in its time. But it's literally 4 decades old: it would be unreasonable to expect it to not show signs of age.

by xamuel 12y ago

copsarebastards 12y ago

> It's kind of like saying: trauma surgeons must be more dangerous than pediatricians, because so many more patients die in the care of a trauma surgeon than in the care of a pediatrician. It ignores the fact that you wouldn't send a pediatrician to such a difficult patient as you'd send a trauma surgeon to. You wouldn't use Python in a lot of the places you'd use C because the performance would be "shaggy puppy meets Godzilla" lousy. You can make any argument by analogy. > Suppose I've established that the fastest way the computer can do X involves having the CPU (which only knows machine code, no magical languages) access a memory location without checking if it's in bounds. Either the language allows me to program that, or it doesn't. If it does, then Heartbleed-like bugs are possible. QED. Suppose we don't suppose things that are wrong. Static type checking can check bounds at no runtime cost this in many cases. Like I said, your argument is based on ignorance of the alternatives. > Alright, there's technically one other alternative, require the programmer to formally proof-verify that the code does as it's supposed to. I hope that this will become more practical within my daughter's lifetime (it probably won't within mine). I'm not hoping for 100% formal verification here, I'm merely hoping to be significantly better than C. That's a very low bar: C does very little checking. Why on earth would you be opposed to this? In fact, I don't think we'll ever be able to 100% formally verify that a program does what it's supposed to. You can verify some things, like memory access, but in the end we'll never be able to 100% verify that the thing we are verifying is the desired behavior. Look, I'm not criticizing the people who made C or the people who wrote tons of code in C. C was a great language in its time. But it's literally 4 decades old: it would be unreasonable to expect it to not show signs of age.