Could Python supplant Java?

brueckd at brueckd at
Thu Aug 22 06:17:01 CEST 2002

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

> > Tsk, tsk. C'mon, you aren't even trying to educate yourself:
> Sorry, at that point I was still stuck on the garbled google reference.
> This is very informative and answers a number of my questions, thank you.
> >,1058265116,1057803298,1057549521,1057684304,1057548935,1057610154,1057583289,1057548115,1057444425,1057425474,1052261415&seekm=KHkL8.21383%24eD2.2399923271%40newssvr10.
> >= 100K: 2
> ca 50K: 3
> ca 30K: 2
> other "big" but unspecified: probably easily more than above
> Not very precise but starts to give me a feel.  Shuts down my "any
> >100K?" rhetoric.
> Given the number of participants on the list, I suspect my conjecture
> about most people's experience being on small, one person projects still
> is true.

I don't disagree. That seems to be universally true regardless of 

> > Also (as has been mentioned before), you are still comparing apples to
> > oranges because Python programs tend to be far shorter than their C++ or
> > Java counterparts. Thus, a 100KLOC Python program could easily, in terms
> > of complexity and functionality, belong in the ranks of million line C++
> > programs.
> 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

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.

> 1. This book takes concrete data from hundreds of software projects and
> extracts the important factors that affect cost:
> >From it we learn that one of the biggest factors affecting cost of any
> >software project is it's size.  Cost is not linearly proportional to
> >code size but rather it increases geometrically.  One contributing
> >factor is the increased lines of communication when you add project
> >team members.


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

> 2. Carefully consider my other arguments [posted elsewhere] including
> the reference to the No Silver BUllet article..

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

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

> 3. Tell me how even this small example program could be made 10X better
> than it's C++ equivalant:

What??? After all the talk of 100K+ programs you cite a 300 line 
C++ program?? ;-)


More information about the Python-list mailing list