Could Python supplant Java?

[James J. Besemer]

brueckd at tbye.com wrote:

> Well, I guess I'll have to buy the book and read it.

There's a second edition, might be even better.

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

That is true and would be reflected in the cost estimates from a properly
calibrated COCOMO model.

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

That makes sense.  I suspect the necessarily larger LOC values would naturally
drive many of the other costs.

In all fairness, though, COCOMO wasn't designed to compare radically different
development scenarios.  It's claim is that once calibrated in a particular
operating environment it will be a reasonable predictor for future work in that
same environment.  In the two scenarios you mention there'd be lots more than
just the language parameter to tweak.  Stupidity of managers for doing things
that way, for one.  ;o)

In developing the model, using data from tons of actual projects, some general
observations came out, which I took to be the big lessons from the exercise.
Then I tried to interpolate back to specific predictions and there are too many
unknowns for that to work.

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

Andrew Carnige, the steel baron, was a huge believer in automation.  He invested
huge amounts of capital whenever he could.  People hated him because he
consequently put workers out of work.

Too many software development Silver Bullets may put some of US out of work.

=8^0

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

My two examples were more the same but it was a number crunching application, one
which Python was not originally designed for.  Some other application heavily
biased towards string or list processing I am sure would be significantly
smaller.  And the libraries are not to be underestimated.  I once wrote Perl
script to parse incoming CGI and it wasn't pretty and not just because it was in
Perl.

Thanks for the interesting discussion.

Regards

--jb

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