Python Productivity Gain?

[Dave Brueck]

beliavsky wrote:
> Another point. Python advocates often claim it is better than compiled
> languages because the code is much shorter. They rebut worries about
> the loss of safety by recommending unit testing. In a Fortran 95 or
> C++ program, I don't think as many tests need to be written, because
> the compiler catches many more things. If you include the amount of
> testing code when counting the amount of code needed, I suspect
> Python's brevity advantage will partly disappear. Also, I regard unit
> tests to check what happens when a Python function is called with
> invalid arguments (int instead of float, scalar instead of array) as
> low-level, tedious work that I would rather delegate to a compiler.
> Scripting advocates claim that their languages are higher level than
> compiled languages, but in this case the reverse is true -- the
> compiler does more work for you than the interpreter does.

Interesting thread! One minor nit though: writing the type of low-level tests
you describe above is almost always a no-no for Python programs. Good tests
tend to be geared towards functionality, so that the number and type of tests
correlates more closely to the features and algorithmic complexity of the code
than it does to the language.

Those ultra tedious low-level tests are usually a waste of time because they
end up covering cases that either never happen in practice or cases that are
already covered by tests that cover real functionality. In fact, really the
only time where I've come across the need for those types of tests is in
_other_ languages (C++) because they are more common in languages that require
the programmer to manage more details, and because failing to test those
conditions results in a hard crash of the program (tests like "properly rejects
null pointers passed in" and "doesn't access beyond array bounds").

IOW, in the *worst* case you invest the same amount of time and effort testing
your Python application as you spend testing your C++ (or whatever)
application - I haven't come across ANY case in practice where you end up
investing more effort; in fact I'd say that in our projects we end up spending
considerably less effort because (1) we get to skip precisely the type of tests
you're talking about and (2) the setup/teardown/test code is much more consise
and reusable (which is why in the past we've used Python as the test language
for applications written in other languages).

In theory, yes, you could have a Python function that gets passed a scalar when
it was expecting an array, but in order for that to occur you almost always
have a gaping hole in your suite of higher-level _feature_ tests. With adequate
feature and system test coverage (which you'll need regardless of the
implementation language), the probability of encountering a scalar vs array
error is way less likely than e.g. a null pointer access bug.

-Dave