Could Python supplant Java?

[brueckd at tbye.com]

On Fri, 23 Aug 2002, James J. Besemer wrote:

> The model I was referring (COCOMO) to says that code size affects the
> cost of the overall project.  Size affects the project more than any
> other factor except for personnel and it affects project costs in a
> decidedly non-linear fashion (polynomial or exponential, I don't
> recall).
> 
> In this model there is a separate 'knob' for language power.  Over lots
> of projects, with lots of languages, the 'language' knob had much less
> effect on project cost than mere code size (holding language constant).  
> IIRC language also affected cost according to code size only the
> contribution (savings) was "linear" on code size.
> 
> With the proper setting for language, the model would predict different
> costs for the same number of lines in two different languages such as C
> and Python.
> 
> I was saying that on large projects the linear factors become insignificant
> because the non-linear factors overwhelm the computation.  That is:
> 
>     k1 * LOC + k2* exp( LOC ) + otherStuff( LOC )
> 
>     is similar to k3 * exp( LOC ) + otherStuff( LOC )
> 
>         for very large values of LOC.
> 
> This holds even if the language efficiency (k1) is very small (high
> efficiency) because the overall size factor (k2) is known to be the
> largest one.  [These aren't the real COCOMO equations -- only a grossly
> oversimplified example to explain my point.]
> 
> Intuitively, Python may help but on really large projects you need to
> add extra computers, managers, secretaries, vacation time, and support
> personnel (greatly adding to cost) but the use of Python vs. C doesn't
> affect those portions of the cost model at all.

Well, I guess I'll have to buy the book and read it. My point was simply
that, if a language lowered LOC and increased productivity of individual 
developers, in terms of pure development costs it effectively converts the 
large project into a smaller one. You don't _need_ as much personel, as 
many communication paths, meetings, managers, etc.

Going back to the assembly vs. C example, if I had to manage development
of a modern word processor in assembly and you had to manage the same but
in C, compared to you my staffing requirements would be bigger and my
planned and actual release dates would likely be farther out because doing 
it all in assembly is a massive project while doing it in C is perhaps 
just a big project.

This certainly isn't limited to just computer programming:  a
semi-automated manufacturing plant with the same output as one staffed by
legions of human workers will "win" because, even though revenues might be
the same, the former has much lower costs; the "tools" used produce enough 
leverage to make the entire process itself much smaller and leaner.

> > No, because I already cited from my own experience a mid-range program
> > (not quite 100k lines) that gave 8X difference in lines of code.
> 
> You just don't want to admit that you can't improve my example to 1/8
> the size of the C++.  ;o)

Can't or don't want to... there's probably some truth in there either way.  
;-)

> Seriously, your and others' anecdotal data has given me pause.
> 
> > This morning I found another example:  [...]
> > Here's the line count with the ratio of lines to Python lines:
> >
> > C++: 786 (8.3x)
> > Java: 466 (4.9x)
> > Python: 94 (1.0x)
> >
> > The Java one was implemented first, followed by Python, followed by C++,
> > although they were all implemented independently of each other.
> 
> I have to ask, did the Python version by any chance make use of some
> large XML library not available to C++ or Java?  If so that would not
> necessarily undermine your argument from a practical standpoint but it
> also would help explain some of the claims I have trouble believing.

No, all three used typical XML and database libraries. I don't want to try
and read too much into this one example because it is after all a single
data point, but at the same time it's pretty rare to have 3 versions of
the same (albeit small) program that do the same thing but were not
created as the result of some sort of competition to see which language is
best.

-Dave