Could Python supplant Java?
joeking at merseymail.com
Wed Aug 21 14:35:45 CEST 2002
Peter Hansen <peter at engcorp.com> wrote in message news:<3D62C9AB.D6A6CE34 at engcorp.com>...
> FISH wrote:
> > Dynamic types are less
> > hassle to work with, but of course they push an added burden of
> > testing onto the developer - because mistakes are not so easily
> > spotted.
> I would agree they push an "added" burden on those developers who
> would not otherwise test their code...
I would see static typing as "extra" testing - pre bug-testing
testing, if you like.
It can't hurt to have *two* lines of defense against bugs, now
can it? :-)
> > This is one of the reasons why I do not consider Python a suitable
> > alternative to Java. Dynamic typing is fine for scripts, but when
> > it comes to full-blown 'ten thousand line' applications you really
> > should be looking as something IMHO which gives you the added
> > security of strong typing, to catch as many potential bugs as
> > possible.
> Damn. We'll have to throw out our 10000-line-plus applications
> and the many lines of test code, since obviously using Python cannot
> work. We'll have to retrieve the various products from the field, as
> well, and tell our customers they were delusional when they thought
> they were using them successfully. ;-)
I didn't say that you *couldn't* do 10,000 line plus code in
Python. But that programs of that complexity are often safer
when coded using static types.
Obviously the 10,000 line thing is just a generalisation, a
shorthand if you like. There can be thousand line programs
which are actually quite simplistic, and there can be 10 line
programs which are as complicated as hell (most of them written
in Perl, for some strange reason :-)
> Really though, your beliefs are shared by many, but not necessarily
> valid. Many of us have written many many programs in statically
> typed languages, and yet we find greater benefit in using Python,
> *especially* for very large applications. Why do you think that
> might be? It seems unlikely we all have such poor judgment as to
> be entirely wrong about it...
I agree, in so far as it is a matter of opinion. There's no
right or wrong here - only judgement.
The way I look at it is this: when using a dynamically typed
language, how often do I mix the type of data I store in a
given variable? Although a language may be able to convert
between types transparently (for example, converting the string
"123" into the integer 123) on the whole a given variable will
be assumed by the software to carry one specific type of data
To clarify: When processing a text file line-by-line via a
variable, it matters not if your language automatically converts
lines consisting of only digits into an integer... because any
processing is likely to use everything as if it was text. In
other words, although the language will find the 'optimum'
datatype for each line read in, the proccessing loop using the
variable is likely to treat everything in a uniform way - in
our example it would probably treat everything as a string.
I don't see (personal opinion!) a genuine need to have a single
variable which can mutate between being handled and processed as
a number one minute, and handled and processed as a string the
next (for example). Indeed, I consider such overloading of a
single variable potentially confusing (and therefore bordering
on bad practice).
If I wanted to make use of the automatic conversion of types
offered by some languages, I would much rather this shift in
interpretation was *explicitly* documented in the code (by
using a conversion function, like atoi() for example) rather
than just allowing a 'digit filled string' to be treated as
an int as if by magic! :-)
So, given that I've always been extremely weary of 'overloading'
variables to handle multiple data types, static typing for me
has the added benefit of allowing the compiler to double check
my work, while not really taking anything away. Sure - I have
to do a little bit of extra work to actually *think* about the
type of data I need to use... but I consider all that just part
of good software design.
Like I said, opinions differ.
More information about the Python-list