Could Python supplant Java?
brueckd at tbye.com
brueckd at tbye.com
Tue Aug 20 17:06:00 CEST 2002
On 20 Aug 2002, FISH wrote:
> > IMHO, compile time type-checking is a nice safety net, but if you get a
> > type error at compilation, it still means you made a mistake.
> Yes, but the error is flagged in compilation, as opposed to
> five weeks after the product ships, when it crops up in a bug
> report from a customer.
Have you done any analysis or classification of your bugs that actually
shows that the bugs found in production would equate to syntax errors in a
compiled languaged? Anecdotally they tend to be two different types of
bugs; also I just scanned through our entire internal Bugzilla list and
see two things:
1) The production bugs in C++ and Java are similar to the ones in Python.
2) None of the Python bugs would have been found at compile time in a
> Strong and weak typing have their place. Dynamic types are less
> hassle to work with, but of course they push an added burden of
> testing onto the developer
You are deceiving yourself if you think (at least a good portion of) the
burden of testing is not already on the developer. The difference between
static and dynamic typed languages is that with the dynamicly-typed
language you don't have the false sense of security. You should be
suspicious of all warm fuzzies derived from code that successfully
> 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
I think you mean 'static' and not 'strong' typing as Python *is* stronly
The perception that dynamically-typed languages don't work for large
applications is common, but it is a common *mis*conception (for example,
Google for one of the recent threads about successful large Python
applications - despite Python's limited popularity there are actually
quite a few large and successful Python projects - certainly too many to
be a fluke!).
One reason why your fear doesn't turn out to be true is the reason I
mentioned above: the bugs found in the field aren't the kind caught by
a compiler. They are algorithmic or coverage bugs - much higher level than
syntactic errors. They are bugs that stem from false assumptions or
unanticipated scenarios - the same screwups you make whether your language
is Python or C++. The difference is that in, say, C++ you have these kinds
of bugs PLUS the bugs that are due to incorrect memory management, use of
lower-level data structures, rigidly defined data types, etc. You end up
having MORE bugs because the developer has to manage far more details.
I'll go so far as to say that languages such as C++, VB, Java, are
actually *less* suitable for very large projects than Python, and their
suitability *decreases* as the size of the project increases. Languages
like Python actually enable the clean and robust creation of larger
programs by smaller groups of people - its clean syntax, high-level
built-in data types, automatic memory management, low cost of change, etc.
all combine to push back the limits of program complexity - the point at
which the application becomes too large and complex to manage.
Whatever comes after Python will further extend the limit of what a
program can be before becoming too complex. Moving from assembly language
to C opened the door to larger and more complex applications for the same
reasons, and moving from C++ or Java to Python yields similar results.
> > in C, you can have type error when casting a void*, and you don't have
> > any info about the original type of the pointeur. Dynamic typing doesn't
> > means Python is not *strongly* typed.
> Surely the two are mutually exclusive? Unless this is some very
> novel use of the word 'strongly'? :-)
No. From section 3.1 of the Language Reference:
"Every object has an identity, a type and a value. An object's identity
never changes once it has been created ... An object's type is also
Don't confuse objects with references to objects.
More information about the Python-list