Could Python supplant Java?

Duncan Booth duncan at
Thu Aug 22 18:36:54 CEST 2002

joeking at (FISH) wrote in 
news:dbc5020.0208220730.39536ae0 at

> 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 

> 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
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