Could Python supplant Java?

[brueckd at tbye.com]

On 21 Aug 2002, FISH wrote:

> > > 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. 
> 
> I never said it wasn't.  Sounds like we need all the help we
> can get - don't you agree?

I'm in favor of any assistance that results in a _net_ benefit. If the 
downside outweights the upside, then no, I don't agree.

> > 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
> > compiles. :-)
> 
> There's a man who sounds like he *really* has confidence in the code he
> writes :-)

??? No, I'm saying that the 'compiles without errors' milestone means 
little to me.

> > 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!).
> 
> And statically typed languages are not successful?  ;-)

Again, I'm not sure of the point you're trying to make. The discussion was 
around the idea that dynamically-typed languages won't work for large 
projects. The success or failure of statically typed languages is 
irrelelvent.

> > 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.
> 
> Why are you so against the idea of telling the compiler in advance
> what type of data you are going to hold in a variable?  I mean 
> really, what great freedoms do you loose which cannot be regained
> by other (more strucutred) means?

Well for one, I'm not against the idea altogether, but I strongly disagree 
that _not_ telling the compiler in advance is bad or unsuitable for large 
applications.

I don't know about you, but any time I can reliably shift work off my
plate and onto that of the tools, I'm all for it. Why should I have to
waste time thinking about types and telling the compiler about types if
that information adds little or no value? Life is too short for me to
spend my days deciding whether a 16-bit integer is 32-bit integer would be
best. Unless it's going to make a real difference (and for the
overwhelming majority of my work it does not), then that's not work I'm
interested in doing.

The other problem I see is that of forcing the developer to give more type 
information than he really has at that point in time. I've seen my share 
of convoluted class and interface hierarchies that are, at least in part, 
the result of some programmer trying to amend his thinking or reuse some 
code, but in order to do so must first come up with an all-encompasing 
classification for his objects so he can be allowed to proceed. Bleh.

> I know for some small applications it is overkill - but surely any 
> serious programmer would want all the help she can get - even if it 
> does only catch 1% of bugs.

The problem with this line of thinking is that it considers the benefits 
in isolation of the drawbacks. If you feel better about using 
statically-type languages, go for it. But I have found real, tangible 
benefit to using dynamically-typed languages, and there's ample evidence 
that others have too, including work on some very large projects.

-Dave