Typing system vs. Java

John S. Yates, Jr john at yates-sheets.org
Thu Aug 2 20:09:32 EDT 2001


Disclaimer: I am just begriming to get my feet wet in Python.

I have been programming for 30 years, starting with papertape
on a PDP-8 and a KSR 33.  That means I spent a long time
coding in assembler.  In the late 1970s I joined DEC (Digital
Equipment Corp) and had the joy of "graduating" to a "high
level" systems programming language: BLISS.  The important
point for this discussion is that BLISS is (was?) type-free.

Being released from managing registers and from generating
labels and branches meant I could code faster and tackle
projects I would never have contemplated in assembler.  In
this case the project was a brand new optimizer and code
generator for a VAX Pascal compiler.

While I was building that backend I was also absorbing the
concepts of "strong" type checking.  Regularly I found myself
getting to the end of a debugging session only to discover
that "Gee! If I had been coding in Pascal this error would
have been caught at compile time".  Such bugs frequently
involved argument mismatches, values chosen from the wrong
(simulated) enumeration, etc.

This impression was born out at the end of the project when,
with a now fully functioning Pascal compiler in hand, I set
out to reimplement the project's bug tracking system.  I found
that I regularly did major clean-up on the system with great
confidence knowing that once I got through an error-free
compile the system would work as well as it did before the
clean-up.  In the BLISS work I had never felt that confidence.

Python is not as bad as BLISS since values at run-time carry
their types and these are checked.  But the difference feels
very much a kin the the difference between Pascal or Ada and
old, no prototypes, no true booleans, all enumerated values
are really just ints, K&R C.

Once I get my Python code running I find I am loath to change
it.  The system does not help me find every site that needs to
be updated.  Only runtime execution can do that.  Which places
a greater value on unit testing and coverage analysis.  And the
investment I make in those areas detracts from the rate of code
evolution.

I find that Python supports rapid prototyping but not necessarily
rapid evolution and solidification.

/john
--
John Yates
40 Pine Street
Needham, MA 02492
781 444-2899



More information about the Python-list mailing list