Blind faith (computer programming)(en.wikipedia.org) |
Blind faith (computer programming)(en.wikipedia.org) |
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.
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.
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.
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.
[1]: http://catb.org/jargon/html/V/voodoo-programming.html
[2]: http://catb.org/jargon/html/C/cargo-cult-programming.html
Why do we have bloody exceptions if we need to double check every action taken?
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...
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.