Could Python supplant Java?
will at misconception.org.uk
Wed Aug 21 21:58:52 CEST 2002
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++.
More information about the Python-list