On Tue, 28 Aug 2007 23:45:28 -0700, Russ wrote:
On Aug 28, 10:58 pm, Michele Simionato <michele.simion ...@gmail.com>
wrote:
>Why do you think that would ad a strong positive capability?
To me at least it seems a big fat lot of over-engineering, not
needed in 99% of programs. In the remaining 1%, it would still not
be needed since Python provides out of the box very powerful
metaprogrammin g capabilities so that you can implement
yourself the checks you need, if you really need them.
I get the strong impression you don't really understand what
programming by contract is.
I have not yet personally used it, but I am interested in anything
that can help to make my programs more reliable. If you are
programming something that doesn't really need to be correct, than you
probably don't need it. But if you really need (or want) your software
to be correct and reliable as possible, I think you you should be
interested in it. You might want to read this:
http://archive.eiffel.com/doc/manual...iane/page.html
I agree with Chris - there's no need to be condescending.
However, I agree with you that this is a valuable addition to a language.
It's not that Eiffel, by having preconditions and postconditions, is doing
anything that cannot be done in python already.
It's more that by making these things a formal part of the language, or at
least a module that facilitates them, one gives a sort of stamp of
approval to adding a ton of assertions about how your code is supposed to
work /when/working/in/that/language, which makes debugging a relative
snap. Isn't that something people should want for python? Sturdy code
and easy debugging?
I've been trying to write my python code with tons of "unnecessar y" if
statements that check out my assumptions, and I'm finding more or less
what the Eiffel people claim: I'm investing a little bit of upfront time,
and getting a huge payoff in the backend as my code starts to debug
itself. But I likely never would've started taking my error checking to
such extremes if I hadn't been curious about Eiffel for a while.
Throwing in tons of error and assumption checking mostly eliminates silly
tracing from procedure to function to procedure to function, trying to
find the ultimate root cause of a problem. Usually, the root cause is
identified in an error on stderr or similar.
Keep in mind that debugging usually takes far longer than the initial
coding. Programming by contract seems to balance that out, relatively
speaking.
Granted, we could just say "You should check for these things anyway", or
"You should know what you're doing", but... Isn't that kind of what
assembler programmers used to say to Lisp, FORTRAN and COBOL programmers?
And what about the case where you've written a piece of code, and
someone else has written another, and the two pieces of code need to
interact? Odds are pretty good that if this code has much substance,
there'll be opportunity for subtly different assumptions about what should
be happening in each (yes, "well abstracted" code will be
misassumption-resistant, but even the best OOP programmers will run afoul
of this /sometimes/). Perhaps both these programmers "Know what they're
doing", but they don't necessarily know what the other is doing!
IMO, putting Programming by Contract into python as part of the language
itself, or as a simple module, is a little bit like a company or
department coming up with a mission statement. It's easy to say that it's
meaningless, and some will ignore it, but it still kind of sets the tone
for how things "should be done".
