Could Python supplant Java?

[Duncan Booth]

joeking at merseymail.com (FISH) wrote in
news:dbc5020.0208280346.36b442c3 at posting.google.com: 
<snipped>
> All you have checked here is that your function returns a valid
> result if you pass it valid arguments.
> 
> That's important, of course, but rather simplistic.  A very hefty
> proportion of errors come when invalid or unexpected data is passed
> into a piece of code.  ie. you feed in -99 as someone's age, or "" 
> (empty string) as someone's name.  With dynamically typing you have
> the added complication of having to deal with "" as someone's age
> and -99 as someone's name.

That is because I followed the rule of writing only one test, then 
implementing the code for it. If it is a requirement (even an unwritten 
one) that the code handle an age of -99 then there will be a test for it.
If there isn't a test (because we are both agreed that the tests won't 
catch everything) and a bug is later found, then at that point a test would 
be written. I note a report in a recent comp.risks of a 103 year old 
pensioner told to report to a local hospital and bring his parent with him.

> The assertions are necessary, because the programmer calling my
> code may well have transposed the arguments, or simply provided
> the wrong types.  On 'big projects' the chances are I will be
> writing code which will (a) be called by someone else's code and/or
> (b) be maintained by a team rather than a single programmer.

I had to maintain some code the other day where someone had transposed the 
arguments. Unfortunately they were of the same type, so the static type 
checking in that language didn't catch it.

I would expect transposed arguments to be caught by a unit test, probably 
involving a mock object. This should catch the actual values being 
transposed even if both values were 'sensible' for either position.

<snip>
> When you are 
> writing huge applications with several programmers, trapping 
> 'interfacing' problems (passing bogus or incorrect data) is a 
> problem.  Static types help solve some of that problem.

True so far as it goes, but static types are not the only (nor IMHO the 
best) way of achieving this.

> 
> [snipped...]
>> I haven't checked that the callers of this function are passing in
>> suitable parameters. That is because I'm not testing them, I'm
>> testing WordWrap here, and anything that uses it will get tested
>> elsewhere later. 
> 
> So you end up writing the test code anyway, it just gets shifted
> elsewhere... :-)

Yup, it gets shifted to the context of testing the caller, not testing the 
callee. If the caller gets it wrong, this is where it should be detected.

<more snipping> 
> Check the spec.  It'll be in there  :-)

I suppose you always work from complete specifications, signed off by the 
customer before work began, with no ambiguities and no mid development 
changes of direction. I am seriously impressed. Care to share the secret?

> [snipped stuff about Challenger...]
>> And statically typed languages help with this precisely how?
> 
> Nothing.  As I explained in the original post, it was an aside
> about testing in general (and placing too much faith in it,
> specifically! :-)

A better example then would have been Pathfinder. That was a case where 
insufficient software testing cost a lot of money. This is an argument 
against doing insufficient testing, but I hope you aren't saying they would 
have been better off without doing the testing?

<snip>
> The lesson is, I would assume, that testing - no matter how
> strict, how intensive and how meticulous - will never stop
> errors from getting through.  The advantage of static typing
> is that it imposes a disipline on the programmer which just
> lessens the burden of having to trap all those bugs in testing.
> Or to put it another way: as testing is not a precise science,
> you should attempt to stop as many bugs from getting to the
> testing stage as possible.

My rather different viewpoint is that as testing is not a precise science, 
you should do everything in your power to stop it being a separate stage at 
all.

[This is getting a bit off topic for comp.lang.python. If you want to 
continue this discussion you are welcome to email me, however I suspect we 
are unlikely to shift our positions substantially.]

-- 
Duncan Booth                                             duncan at rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?