Could Python supplant Java?

[brueckd at tbye.com]

On Wed, 21 Aug 2002, James J. Besemer wrote:

> The trade-off is that in exchange for pre declaring your types
> the compiler detects and helps eliminate this class of bugs even
> before you run your unit test.  The cost of declaring ahead of
> time is small and the gain to be had (vs. debugging each of the
> corresponding runtime errors) can be significant.

There are more costs involved: forcing the developer to be more explicit
about types than he is ready to be comes to mind. Saddling the programmer
with managing mundane type details also cuts into productivity and
increases the changes for errors. Heck, in languages like Java the actual
cost of all the extra _typing_ is worth considering. I'm not totally 
against compile-time checking, but the costs aren't as small as you think.

> Common errors such as type mismatches and wrong type
> args to functions are syntax errors in C++.

Often but not always, yes.

> But in Python they produce some kind of aberrant runtime behavior.  In
> lucky instances, an exception occurs close to the function definition
> and trace back shows you a list of candidate offending callers to search
> back from.

Ahh.. now I see. This is more true if you strictly adhere to a
comple-run-debug development style. The more I develop in Python the more
it becomes much more interactive, so in practice most of these bugs are
caught very early and very "close" to where they live. I find this to be
much more productive anyway, and use the same approach for any Java
development I have to do: once I actually do the compile step I'm
compiling code that has largely been tested interactively via Jython.

> Furthermore, I don't see a huge benefit to being vague about types.
> Very few python programs make use of the fact that a variable
> or a function parameter can take on a variety of types.

That's not the only benefit, and IMO, not even the most important. For me 
a huge portion of the dynamic-typing benefit is that my programs act as if 
they were written in a statically-typed language with a very smart 
compiler. By this I mean that it's as if the compiler magically figured 
out what type I meant and took care of the details for me instead of me 
having to do the hand-holding. 

I believe this is why many people talk about programming in Python and
similar languages as being "fun" or "liberating" - you don't spend lots of
time and effort doing the really mundane work but instead do real work. As
an analogy, imagine that for every C function, you were in charge of
register allocation for all your variables. That's how I feel now when I
write C++ programs and have to declare everything before I use it and
assign a type. It makes my want to throw up my hands and say to the
compiler, "sheesh, why can't you figure it out on your own??"

> But it can hurt on large projects in the long run.

The overarching thing you should take from this thread is that, yes, it
can (could) hurt, but in practice it doesn't seem to. This is a popular
issue to bellyache about in the realm of theoretical problems, but few
complain about it out of actual experience with a large project. In 
practice either it causes little or no problems at all, it is taken to be 
a price worth paying, or large project developers have all been paid off 
by the PSU. ;-)

> > 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!).
> 
> First off, I don't think 10K lines is that big of a project.

Me neither.

> I hear Zope is the one big Python APP and everything else is an
> also ran.  I accept this may be obsolete data but where is the
> current data?  Is there a reliable enumeration somewhere for
> Python?  Ideally one would like to see a histogram of lines of
> Python indexed by project.
> 
> Your paragraph is pretty garbled.  Am I reading it properly that you
> are claiming Goggle as one of Python's large project successes?

No, I typed 'Google' and meant 'google'. Specifically, search the Google
archives of comp.lang.python because a month or so ago there were several
posts on some large Python programs. What's interesting to me is that some
of these programs were > 100k of _Python_, meaning it's not much of a
stretch to say that equivalent implementations in C++ could be on the
order of a million lines of code. Surely that meets your criteria for a
large program?

> > 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.
> 
> As a statement of opinion, nobody can argue.  But as a statement
> of fact (as you've written it) I think it's more accurate to say the jury
> is still out on this trade-off.

Well of *course* it's opinion. This is Usenet.

>  Certainly the substantially larger installed
> bases in Each of the three alternatives is a partial counter-argument.

Uh, no, because you can't cleanly deduce _anything_ about suitability from 
user base size - there are too many other factors that weigh in much more 
heavily.

-Dave