Could Python supplant Java?

[James J. Besemer]

brueckd at tbye.com wrote:

> On Wed, 21 Aug 2002, James J. Besemer wrote:
>
> > This is utter bullshit.  Python is certainly not going to give anybody a
> > 10:1 advantage over C++ on a large scale project.
>
> I guess it depends on your definition of 'advantage', but I've found that
> in terms of lines of code 10X is not unrealistic. Unfortunately the only
> true data point I have (the largest direct port of a program I've done
> from one language to another without adding significant functionality) was
> 80K lines of C++ to about 10K lines to Python. That's 8:1, so maybe 10 is
> too high for the general case, but having written similar libraries in C++
> or C or Java and then in Python, that general decrease is code size is
> common.
>
> The other example that comes to mind is a company I worked for that
> prototyped the entire system in Python, resulting in 25k to 30k lines.
> Despite the fact that there were no peformance problems and most of the
> functionality was actually working in the prototype, the development-level
> management insisted on keeping it as a prototype and rewriting it in Java.
> IMO the project became unmanageable at 150k lines of code and about 75% of
> functionality complete (although I'll admit that many of those problems
> were not related to the language used), the product was endless delayed,
> and the company went out of business.

I'll withdraw my strong objection but I remain skeptical of such high claims.

I think they MAY be true on small projects but I don't believe it scales up.

> > As projects grow in size, individual factors such as the programming
> > language used become increasingly irrelevant.
>
> If that is the case, it is _only_ true if the languages yield programs
> roughly the same size in lines of code. Your own 'geometrically
> increasing' comment above proves this: if writing a program in language B
> takes twice as many lines as in language A, then, all else being equal,
> the cost of using language B is _more than twice_ the cost of doing it in
> language A, possibly much more. Intuitively this makes sense too: few
> people are crazy enough to implement any of today's large applications in
> assembly language.

What you say is true but the cost of using either language is but a small part of the overall cost of developing a large project.

I'd furthermore submit that the cost of using language A vs. B gives you a constant cost savings overall and does not scale geometrically (as do the overall costs).

> Switching languages can result in a huge decrease in code size as well as
> a huge increase in productivity. I don't understand why this seems so
> implausible to you. I use Python over C today for _precisely_ the same
> reasons I moved from assembly to C way back when. To me it _was_ a silver
> bullet. I got the same amount done in C as I did in assembly but in far
> less time, far fewer lines of code, and far fewer bugs (not to mention far
> fewer maintenance headaches).

I'm not saying changing languages can't help or that Python isn't better than C++.  I only have trouble with the claims of order of magnitude improvement.

I think assembly to C is a profound improvement, as it amounts to a paradigm shift (though some detractors insist C is merely a fancy assembly language).

C to C++ also is a paradigm shift, as C++ facilitates OOP.

> By no means is Python the end. At some point we'll probably move on to
> something higher level, and it'll allow us to create even more complex
> programs than before without the costs spirally out of control (but for
> performance-critical stuff we'll drop down to a lower-level language like
> Python ;-) ).

Yeah, when we just can't seem to get the inference engine to do what we want, we'll revert back to procedural language.  ;o)

> >     http://www.cascade-sys.com/~jb/Pythonetics//glob/
>
> What??? After all the talk of 100K+ programs you cite a 300 line
> C++ program?? ;-)

If it is true that Python is 10X better than C++ then it seems there should be a way to illustrate it on this small but non-trivial example.  When writing these programs I was more interested in performance and made the programs as similar as possible.  I haven't thought
about it but perhaps there's some way to shrink my Python solution another 8X or so to get down to the 10X range.

If you think a larger program would serve better to illustrate, I'm sure I can come up with one.

Regards

--jb

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