Python vs .Net

[Greg Brunet]

Hi Peter:

"Peter Hansen" <peter at engcorp.com> wrote in message
news:3E1A3F8B.8D4BAD96 at engcorp.com...
> > [...]  I don't see the need to
> > increase the amount these tests in order to catch stuff that the
> > compiler can otherwise find for me (when statically typed).  Also, I
(1)
> > wonder how many folks really do this to the necessary degree in the
all
> > of their apps (I haven't seen this kind or degree in test code in
the
> > Python code that I've reviewed so far,
>
> Definitely not everyone does it (yet?).  On the other hand, some
people
> *are* doing it.  For one thing, much or most of Python's own code has
> extensive unit tests (check out the /lib/test folder).  As another
good
> example, the Twisted framework was developed using XP and has unit
tests
> using the PyUnit test framework.  See http://twistedmatrix.com/ for
more.
>
> The fact that few are doing this doesn't invalidate the concept.  It
just
> means that many have ignored good advice for decades.  The emergence
of
> the new "agile" development methods means that more are being exposed
> to the benefits for the first time, and in a context which makes it
> much more likely they will actually be able to build such tests.

I agree - I don't believe that it invalidates the concept.  But what I
think that it does show is that for many programs, even the validation
that can occur with static typing is missing from the development cycle.
Likewise, just because static typing does help catch these things
shouldn't be a crutch or excuse for me not to run stringent unit tests.
I'm just trying to point out that in many 'real world' cases, the unit
tests don't get written, and so the developer doesn't even get the
opportunity to catch the errors that could be eliminated with static
typing.

> > and (2) unit testing something
> > for different conditions DOES NOT relieve you of the need to add
error
> > checking code, and I have seen virtually none of the error checking
code
> > I would expect in the stuff I've reviewed.  Does all your code check
to
> > make sure that you are passed an integer instead of a float or a
string?
>
> Actually, in many cases it *does* relieve you of the need for error
> checking code.  I likely wouldn't convince you of this in a short
post,
> but there are books being written on the subject as we speak...
>
> The fact that all the important paths in my code are exercised before
> I release means that I don't need to worry about explicit tests for
> integers versus strings or floats.  My tests give me confidence that
> the function that cares about this is *not* called with bad values.
>
> I also know a number of other things about it that your VB compiler
> cannot possibly tell you.  I know that the logic contained in that
> function actually works.  I know that the value passed in, not the
> constant that I hacked in during debugging and forgot to remove later,
> is actually the one used.  I know that the subroutines called by
> that function are correct as well, and that I didn't use the wrong
> name for something during a cut-and-paste accident.  How would VB
> tell you all that without tests?
>
> I think any discussion which compares Python unfavourably with
> a statically typed language where the compiler can do type-checking,
> but which does not assume full unit testing will be performed, is
> merely a way of justifying code-and-fix hacking in the statically
> typed language.  If you assume proper testing, the advantages of
> the statically typed language are vastly diminished.

Surprising as this may sound, I am NOT of the school that "if it
compiles, it must be correct".  Perhaps there are some static typing
proponents that feel that way, but I think that anyone with even a
little bit of experience will realize the dangers of 'code-and-fix
hacking' & depending on static typing to same him from himself.  I've
only just learned about XP, and am trying to come up to speed on that as
quickly as possible, since it does seem that it would improve the
process.

It seems that some folks believe that my position is static typing
instead of unit testing.  That's not the case - continue to do as much
unit testing as you feel is needed (although I wonder what your
confidence level is in your 'unimportant' code paths <g>).  Static
typing is just another tool to help the development process, and even if
proper testing reduces the advantages of static typing by 50 or 75%,
I'll still take whatever extra advantages I can get when I write code.

--
Greg