Could Python supplant Java?

[Will Newton]

On Wednesday 21 Aug 2002 8:28 pm, James J. Besemer wrote:

> However, there's no reason we can't have static declarations in language
> with these other benefits (unrelated to dynamic vs. static) that wouldn't
> be the best of both worlds.

I would certainly not be opposed to an optional type assertion mechanism, if 
a clear, concise and non-intrusive syntax can be devised.

> C++ actually isn't all that bad because there are simplistic formulas for
> keeping storage problems at a minimum.  Unlike C it is relatively easy to
> write, say, a String class that never looses storage.  That class "auto"
> variables automatically construct/destruct themselves exactly like chars
> and ints is, in the hands of the experienced practitioner, almost as good
> as garbage collection.

"Almost as good" in terms of actual end result, "possibly better" in terms of 
speed, "definitely longer" in terms of development time.

> BZZZIT!  Wrong.  May be true with trivial projects and may be true with old
> fashioned technology like GCC but MS's Visual C++, with incremental

Old fashioned it may be, at least it can handle basic standard compliant C++.
A proper build system with GCC should not be different in speed from VC++.

> compilation AND linking, builds can be much FASTER than Python when
> rebuilding large projects in the middle of the development cycle.  E.g.,
> with one 150K LOC VC++ project I worked on I could change a few modules and
> rebuild in just a few seconds.  In contrast, I just generated a fairly
> trivial 150K Python program and it took almost 3 minutes compile (on a
> machine 4X faster than I used for that C++ project).  I bet a real Python
> program (something other than 'pass' for every other line) would even take
> lots longer.

150k lines of C++ != 150k lines of Python. Take your 150k lines of C++, strip 
out all lines including "delete" and all declarations. Now take out all lines 
of the form:

 a_type a = (a_type)b;

Now take out all curly braces. Now take out all explicit mallocs, etc.
You're getting close to the equivalent lines of Python. 

I also suspect that your C++ was not in a single file either - if Python is 
broken down into smaller files compilation is always per-file and will not 
require recompiles like C++.

> In larger projects, this class of error is doubly costly, because the
> problem is created by another developer but the problem initially shows up
> in your code.  So two people have to grind on it instead of one (especially
> if the other developer is your customer and then even if it's 'his' fault).

Without trying to sound arrogant, I rarely make such errors. I cannot 
rememeber the last time I made an error like this in writing around 2000 
lines of Python in the last few days.

> I measure the entire 2.2 Lib source at 129,078 lines, but it's spread over
> 544 modules, thus averaging less than 240 lines per module.  A bunch of
> unrelated tiny pieces is suitable for a library but it's not the same
> experience as a large application.

...of which you freely admit you have no experience - in fact you imply 
no-one does. My Python code tends to be in small files because I can express 
what I want in a small number of lines and don't have endless helper 
functions to cover up the ugly realities of C/C++.