Blind faith (computer programming)(en.wikipedia.org)
en.wikipedia.org
Blind faith (computer programming)
http://en.wikipedia.org/wiki/Blind_faith_(computer_programming)
12 comments
I don't quite understand this (or rather why this is a wikipedia page). This is literally "blind faith" as defined by the normal wikipedia page; there is not "Blind Faith (electrical engineering) or "Blind faith (civil engineering)".
Also the recommended alternative does not have to be TDD, that is just one engineering practice. One can develop with tests without it being TDD.
Also the recommended alternative does not have to be TDD, that is just one engineering practice. One can develop with tests without it being TDD.
I think most of us have probably deployed fixes without knowing 100% whether it helps, but based on a good hunch from looking at data and code. The reason I keep doing so is because so long as the hunch is good and based on facts, it keeps working.
Tests are good, but there are always those issues those 0.001% issues that will never occur when you are trying to make them happen, but will happen to somebody once code is deployed. I am reminded of an incident a few years back where I could reproduce it with tests occasionally, but it would literally take me weeks of re-running the test 24/7 before I would hit it again. As you can imagine, I applied some "blind faith" (as in article) fixes while waiting for that stuff to run.
PS: By the rules of wikipedia, this article probably shouldn't exist. Nonstandard terms, not notable, original research, blah blah blah.
Tests are good, but there are always those issues those 0.001% issues that will never occur when you are trying to make them happen, but will happen to somebody once code is deployed. I am reminded of an incident a few years back where I could reproduce it with tests occasionally, but it would literally take me weeks of re-running the test 24/7 before I would hit it again. As you can imagine, I applied some "blind faith" (as in article) fixes while waiting for that stuff to run.
PS: By the rules of wikipedia, this article probably shouldn't exist. Nonstandard terms, not notable, original research, blah blah blah.
A programmer calls a subroutine to save user-data on the hard disk without checking whether the operation was successful or not.
This might not be blind-faith. "Fail-fast" is a legitimate pattern where you don't check for errors, you just let the program fail/terminate immediately.
This might not be blind-faith. "Fail-fast" is a legitimate pattern where you don't check for errors, you just let the program fail/terminate immediately.
But in this case, if you don't check the return value of for example the write() system call, it's more a case of "fail silently" than "fail-fast", which is perhaps the most dangerous form of bug that a program can have.
I find that this is my natural strategy; I only test functions explicitly when they fail.
Not everything needs a snappy moniker and a Wikipedia page. May I suggest the noun "carelessness".
Also read Voodoo programming[1]/cargo cult programming[2].
[1]: http://catb.org/jargon/html/V/voodoo-programming.html
[2]: http://catb.org/jargon/html/C/cargo-cult-programming.html
[1]: http://catb.org/jargon/html/V/voodoo-programming.html
[2]: http://catb.org/jargon/html/C/cargo-cult-programming.html
Reminds me of Knuth famously publishing some code he had never run, with the disclaimer, "Beware of bugs in the above code; I have only proved it correct, not tried it."
Definitely a victim of this. Many times, when optimizing for time.
[deleted]
But wait! Shouldn't file system subroutine check if it actually written what was asked thus marking operation as completed successfully.
Why do we have bloody exceptions if we need to double check every action taken?
Why do we have bloody exceptions if we need to double check every action taken?
I actually find it much easier to code reliable stuff in C where you have to check error conditions manually. If for no other reason that it serves as a constant reminder that the failures happen, and if you're writing reliable software this forces you into consistent habits to handle them.
I feel like in a language with exceptions, since throwing and catching happens inconsistently and haphazardly all around a code base, people are conned into thinking the exceptions will never happen. Usually one of two things happen:
1. The language is like java and it forces you to declare what exceptions you throw, so lazy people just put in lots of do-nothing catch blocks to silence the compiler.
2. The language doesn't have the "checked exceptions" concept, so people literally think no exceptions can happen. They just wait for the exception to make everything blow up.
Often when exceptions are handled, this lack of explicitness makes sure it's done at totally the wrong stack frame to make the judgement call about what to do about it. Then some people do dumb shit like try to catch things like stack overflow exceptions which should rightfully take down the process, and keep running. Not to mention that an exception is just a wacky concept, it's essentially a goto that crosses stack frames... Everyone criticizes goto, but few people will question exceptions...
I feel like in a language with exceptions, since throwing and catching happens inconsistently and haphazardly all around a code base, people are conned into thinking the exceptions will never happen. Usually one of two things happen:
1. The language is like java and it forces you to declare what exceptions you throw, so lazy people just put in lots of do-nothing catch blocks to silence the compiler.
2. The language doesn't have the "checked exceptions" concept, so people literally think no exceptions can happen. They just wait for the exception to make everything blow up.
Often when exceptions are handled, this lack of explicitness makes sure it's done at totally the wrong stack frame to make the judgement call about what to do about it. Then some people do dumb shit like try to catch things like stack overflow exceptions which should rightfully take down the process, and keep running. Not to mention that an exception is just a wacky concept, it's essentially a goto that crosses stack frames... Everyone criticizes goto, but few people will question exceptions...
This is actually the reason exceptions were created - in some languages, such as C, there are no exceptions and so the result of each write needs to be manually checked for errors.
If you're using a language with exceptions, your program will halt if it can't write. If you're using a language with checked exceptions, you'll have to write code to deal with any possible exception that can be thrown.
If you're using a language with exceptions, your program will halt if it can't write. If you're using a language with checked exceptions, you'll have to write code to deal with any possible exception that can be thrown.
A lot of code doesn't have exceptions; it might, for example, be written in C, or C++ in a place where exceptions aren't used. fprintf() and friends don't raise exceptions on failure.
My entire Computer Science education summarized. Blind faith. Every test, every question, every function, every call. Blind faith.
TDD FTW!
Write a function that saves to disk but never checks if it fails? Who cares? If you never use it again, or it never does anything of value to anybody, it's not worth anything.
Craftsmanship is a great thing, but it always exists inside a larger economic context. The guy laying tile in your kitchen doesn't give the same attention to detail as the artisans completing the Sistine Chapel. And this is a good thing! He might not have much education, he buys pre-assembled pieces, and he's liable to just slop it in there. This is appropriate because your bathroom's economic value is miniscule compared to a great cathedral. Likewise, if you're in a startup writing code, you've only got a 1-in-10 chance or so of your code ever having any value at all beyond just playing around. Completely different picture if you're being funded by BigCorp to write version 8 of the Bells-And-Whistles App. Yet some of us insist on treating all this coding the same.
So I am a bit annoyed at the use of the word "faith" in this context. If "faith" is calling functions and expecting them to either execute or terminate the program, CS is replete with faith-based-coding. This entry describes the situation too much in loaded terms.