Could Python supplant Java?

[James J. Besemer]

brueckd at tbye.com wrote:

> There are more costs involved: forcing the developer to be more explicit
> about types than he is ready to be comes to mind.

Oh, come on.  You don't have to be all that much "more explicit" you just give
them a name.  From a discipline of programming standpoint I find it is very
helpful even in rapid prototyping programming to give explicit names to the key
data types (usually classes) long before the behavior is figured out.  If you're
purporting to do XP then you already decided upon carefully chosen names with
your CRC card design.

In other contexts, we all use strings a lot.  I find it helpful to distinguish
strings that were, e.g., raw 'pages' before conversion into HTML and 'cooked'
pages after all transformations are complete.  In a large project it would help
to keep pages from becoming over cooked or under cooked.

Explicit types certainly would improve readability, Python's principle objective
if you believe some members here.

> Saddling the programmer
> with managing mundane type details also cuts into productivity and
> increases the changes for errors.

Where you "saddle the developer" I rather "delegate to the machine those very
tasks that machines excel at over humans".

Keep in mind that (today anyway) I've been arguing the benefits of an optional
extension to Python rather than switching to one of the other languages.  So it
would be there for when you need it but you wouldn't have to use it.  Best of
both worlds.

> 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.

Having done or managed software development for over 25 years I think I have a
pretty good concept of where the cost and benefits truly lie.

> 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.

No, I too rely on an interactive development style.  That's also how I've
developed for the last 10 years or so, regardless of the language, with unit
testing built into each module.  You don't try to run the system until the new
or revised modules all pass their unit tests.

However in C++ at this point I ALSO can be certain that there aren't any 'arg
count' or type mismatch errors remaining anywhere else in the system, as a
consequence of any refactoring I may have done.  It's no guarantee of zero bugs
but in practice it zaps most of them.  In Python the ultimate consequences of
any changes remains a voyage of discovery, to be encountered one at a time, at
runtime, restarting the entire regression test suite over and over again, after
each error.

Incremental development helps but does not eliminate the problem, particularly
across multiple developers.

> 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.

And it never rains and the skies are not cloudy all day.

> 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.

I see.  You are lecturing me on how wonderful things will be once I am
enlightened and finally see all things in their true Pythonetic nature.

My problem is I thought I was REPORTING to this group that it has in fact caused
problems in practice even on medium sized (10-15K) Python apps delivered to
paying customers who also were developing in Python.

I thought I was REPORTING to this group that even on simple Python apps I find
myself tracking down bugs that I long ago became accustomed to having the
compiler take care of for me and it negatively impacts productivity.

Near as I can tell, others are struggling to voice this modest complaint from
the field.

It is this group's refusal even to temporarily consider any new data contrary to
the accepted dogma that makes this seem more and more like a cult every day.

> 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.

Thanks.  I'll check it out.

> 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?

Well, yes, I previously stipulated that 100K lines was beyond the realm of
"small".

However, I find your 10:1 amplification factor, Python to C++ to be absolutely
absurd.

Starting with the admittedly anecdotal, I had occasion once to write an
application in both Python and C++.  Since they both used the same abstractions,
both were very similar (3 main classes) and they came out about the same number
of lines of code (Python was a little shorter).  For a lot of programming,
Python and C++ are more similar than many of you will admit.

More generally -- sure, Python out of the box has lists and strings that are
more powerful than what C++ offers of the box but in the scope of a 100K C++
program I submit that the several thousand lines for that handful of basic
facilities would largely level the playing field.  I've written dynamic arrays
and immutable strings in C++ and there's not all that much to them.  Python also
has a great library of support modules, but such things also exist for C++.

More importantly, once you get beyond programming in the small, most of the task
of programming is in how you compose larger abstractions from the smaller ones
you've previously built out of primitive language constructs.  So in the OOP
world you're creating and manipulating objects out of classes you defined.

With the recent addition of iterators, Python's

    for item in collection:
        item.doSomething()

is only a little cleaner than the clumsiest iterator I ever used in C++:

    for( int i=0; i < collection.max; i++ )
        collection[i].doSomething();

Similarly,

    if object.property():
        object.action()

vs.

    if( object.property())
        object.action();

C++'s declaration

    Class object( args );

actually is a bit simpler than Python's

    object = Class( args )

At least it's not harder.

SO when programming on a large scale, many of Python's (or any other languags')
advantages evaporate.  We're talking a small amount of syntactic sugar and a
tiny reduction in typing.  It CERTAINLY does NOT give you anything close to 10X
leverage.

>From the standpoint of figuring out how to build and use your abstractions, on a
large app, choosing C++ vs. Python doesn't hardly matter except the C++ version
likely will run faster.

True, garbage collection helps but again it's more of a theoretical problem than
a practical with experienced programmers.  It's a much bigger advantage to
newbies who aren't writing large scale applications.

So maybe, 100K of python is worth 110K of C++ but 100K to 1M is a ridiculous and
indefensible assertion.

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

Yeah, I keep forgetting how pointless this all is.

Regards

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com