Could Python supplant Java?
Duncan Booth
duncan at NOSPAMrcp.co.uk
Thu Aug 22 12:36:54 EDT 2002
joeking at merseymail.com (FISH) wrote in
news:dbc5020.0208220730.39536ae0 at posting.google.com:
> But why remove one layer of the testing - that is to say a
> compiler's ability to check you are putting the right data
> in the right places?
There is a cost to static typing as well as a benefit. I hope we can agree
on that.
Part of the cost is that for static typing to work (at least in languages I
know), you have to tell the compiler the types of values that you expect to
use when declaring a function. This means that you have the cost of adding
in those extra type declarations, and when your design changes you have the
cost of changing the declarations everywhere they occurred.
Another part of the cost comes from the time spent working out exactly
which type you want to pass to a function. Do you want to pass a File
object, or a ReadableFile object, or a
ReadableAndSeekableAndTellableAndCloseableButNotWriteableFile object? Do
you already have an interface that describes exactly what you want to pass
in this circumstance. If not, do you define a new interface, and modify
lots of classes to say they implement it, or do you just use an existing
but wider interface, and make sure you classes all implement the wider
interface even when most of the methods are stubbed out. If you need to
define a new interface do you need team meetings to agree it, new design
documents signed of etc. All of these things take time.
There is also the cost from suddenly needing to write multiple copies of
the same function, or from having to use C++ templates to avoid writing
multiple copies of the code. Any time you have to write a C++ template, the
cost is high.
There is another cost when a programmer who should know better sees their
code compiles, therefore by definition 'it must be working' so they ship it
to the test team who manage to report back 3 weeks later that 500 of their
(manual?) tests failed, all because of one little bug that the programmer
should have spotted to begin with. Yes, I know that we aren't talking
either/or for compiler tests and unit tests, but some programmers really do
this. Writing without a safety net is scary, but perhaps there is an
advantage to keeping your programmers scared?
The benefit to static typing is that I expect that when I hit the 'compile
and test' button, I will be told that the code failed to compile, whereas
without it I expect to be told that a unit test failed. Sorry, I must have
missed something there. Let me try that again. If my unit tests are
sufficiently comprehensive I get an error at the same point in time as I
would have got anyway. Nope, I'm not sure I see a benefit.
Actually, most of the time I have to work with code where the unit tests
aren't sufficiently comprehensive. Most of the time Python bombs straight
out if you pass the wrong type of arguments to a function. Occasionally a
problem like this might get through. Not as often as you might expect
though.
> If you read back through what I actually wrote, you'll see I
> don't advocate static typing as an *alternative* to testing,
> but as a way to *compliment* testing. Another tool in the
> arsenal, so to speak. Plus, I freely admit that dynamic
> typing can be useful in circumstances where the codebase is
> tight enough for static checking to be overkill...)
You think that the benefits of static typing outweigh the drawbacks. I am
not convinced. My experience shows me that strong dynamic typing leads to
faster development of reliable code than either strong static typing or
weak dynamic typing. My experience may be insufficient.
> That's why we have different languages with different
> approaches for different jobs... surely?
Definitely, Python is one tool, Java is another, C++ is another, ...
You definitely want to have enough knowledge of a range of tools to be able
to make an informed decision over which one to use and when to use it.
--
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?
More information about the Python-list
mailing list