In article <5C45C4BFBB33409DBF052A4935AA82A8 at ANTONIOPC>,
<arcarlini at iee.org> writes:
Dijkstra was more interested in whether you could
prove that your
program behaved according to its specification.
I've seen a lot of people talk about this kind of approach towards
correctness. The problem is that it doesn't account for buggy
specifications; once you can prove that your program adheres to the
specification, you just need to prove that your specification is
written correctly. In other words, we're now debugging our
specifications instead of our programs and the problem hasn't
substantially changed. The specifications will always need to be
written in something that can be digested by a computer in order to
prove the program correct, so now I've just shifted the problem of
writing a correct program to writing a correct specification.
Fundamentally I've always believed that this approach doesn't fix
anything, it just changes the language in which I have to write and
debug stuff.
Whether your
program worked every time you ran it was less important than
whether it could conceivably fail.
It's been my experience that this is what unit testing (when done
properly) is providing you: confidence that you've exercised every
single execution path in your code, including all the error handling
cases that are highly unlikely to occur when you manually test your
program.
Don't forget that you couldn't meet his
definition of programmer
without being a mathematician.
Mathematics certainly helps, but programming is more than that.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 version available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>