3 ms·

How does effort affect reliability? Even if you consider one as consequence of the other ("it requires more effort to make a reliable C program than the equival

How does effort affect reliability? Even if you consider one as consequence of the other ("it requires more effort to make a reliable C program than the equivalent program in $language") that doesn't make the final product any less reliable.

Anderkent 13y ago
It does when you only have a set amount of effort that you can dedicate on a project. Which is usually the case.
- wonderzombie 13y ago
  I am not sure that's a useful criterion in practice, though. People are fond of saying that languages will not make you orders of magnitude more productive, and I think the corollary is that on average they will not make you orders of magnitude less productive either. (Controlling of course for characteristics of problems and such.) The problem is that there's not really a great way to reason about this, either. If you're talking about how long it takes to write a program in C vs Java, how do you measure time spent writing code vs debugging vs bug fixing, et al? All in all it's certainly possible it takes longer to write code in C, but for all anyone knows, writing more reliable code up front means fewer bugs later on. Code which is more performant by default may lead to fewer performance regressions when someone induces pathological GC behavior. Contrariwise, there's stuff like memory corruption as the OP describes, which is probably way more difficult in a native environment instead of a hosted one. It's hard not to reach the conclusion that we're all just talking out of our hats anyway (myself included).
trapnii 13y ago
it is more about the attitude of a C programmer versus the attitude of a, say, JavaScript or Ruby programmer. Whilest the latter merely assumes "nah, the VM will catch all null pointers as soft exceptions for me, and all exceptions I don't catch, my caller should." the first kind of programmer has learned (the hard way) to respect as much of the error codes a function call can return. "The hard way" is the malicious smiled SIGSEGV dynamic-programming language programmers may laughter about, because it hardly crashes your program, one may say. However, I do believe, that this attitude to think first (how to program right) rather than trying to remember (what could have caused that many 500's on my HTTP server) which I think is the better approach to write more reliable software. Dynamic languages are said to be more convenient for web sites, for example, I'm not denying that one, but those languages just shift the problems back into the future, where, when time has come, you may or may not be willing to attempt to fix the bug you introduced days/weeks/months ago, depending on the urgency. On programming environments (such as C), where types are more statically typed, errors have to be handled manually and with caution, memory has to be managed (more or less) always with an ownership in mind, those programs, that think about these topics from the very beginning, and iron out those remaining bugs over time, are - from my point of view - the more reliable ones. So I can out of my distance second this blog post. It was interesting to read.

Anderkent 13y ago

It does when you only have a set amount of effort that you can dedicate on a project. Which is usually the case.

wonderzombie 13y ago
I am not sure that's a useful criterion in practice, though. People are fond of saying that languages will not make you orders of magnitude more productive, and I think the corollary is that on average they will not make you orders of magnitude less productive either. (Controlling of course for characteristics of problems and such.) The problem is that there's not really a great way to reason about this, either. If you're talking about how long it takes to write a program in C vs Java, how do you measure time spent writing code vs debugging vs bug fixing, et al? All in all it's certainly possible it takes longer to write code in C, but for all anyone knows, writing more reliable code up front means fewer bugs later on. Code which is more performant by default may lead to fewer performance regressions when someone induces pathological GC behavior. Contrariwise, there's stuff like memory corruption as the OP describes, which is probably way more difficult in a native environment instead of a hosted one. It's hard not to reach the conclusion that we're all just talking out of our hats anyway (myself included).

trapnii 13y ago

it is more about the attitude of a C programmer versus the attitude of a, say, JavaScript or Ruby programmer. Whilest the latter merely assumes "nah, the VM will catch all null pointers as soft exceptions for me, and all exceptions I don't catch, my caller should." the first kind of programmer has learned (the hard way) to respect as much of the error codes a function call can return. "The hard way" is the malicious smiled SIGSEGV dynamic-programming language programmers may laughter about, because it hardly crashes your program, one may say. However, I do believe, that this attitude to think first (how to program right) rather than trying to remember (what could have caused that many 500's on my HTTP server) which I think is the better approach to write more reliable software. Dynamic languages are said to be more convenient for web sites, for example, I'm not denying that one, but those languages just shift the problems back into the future, where, when time has come, you may or may not be willing to attempt to fix the bug you introduced days/weeks/months ago, depending on the urgency. On programming environments (such as C), where types are more statically typed, errors have to be handled manually and with caution, memory has to be managed (more or less) always with an ownership in mind, those programs, that think about these topics from the very beginning, and iron out those remaining bugs over time, are - from my point of view - the more reliable ones. So I can out of my distance second this blog post. It was interesting to read.