Could Python supplant Java?

[brueckd at tbye.com]

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

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

But the whole point of your argument was that _size_ was the biggest
factor, so if one language consistently requires fewer lines of code then
it is possibly a _huge_ factor in determining final cost.

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

Ok, you've stated your position but omitted your reasoning. Do you no
longer agree with your earlier position that size is the biggest factor
affecting cost?

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

One way to look at it is as a paradigm shift. Another is to see each
transition as one of letting the compiler and language take care of more
of the mundane details so that more and more of your focus is on solving
the actual development problem. For example, in assembly language, how
much of the actual coding time is spent on problems that are in no way
specific to the task at hand? Or put another way: for each unit of coding
effort (X), what distance (Y) did you move forward towards the goal of
completion? In assembly the ratio X:Y is huge, it's smaller in C, and
smaller in Python.  I'll transition from Python when I find something
that, all else being the same, lowers it further by a significant amount.

Within any particular language, productivity gains are had by adding
"stuff" (macros, libraries, etc.) to make the language more like one with
a smaller X:Y ratio, but at some point it just becomes more cost-effective
to move on to the next language.

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

Wait - my claim was around lines of code. I do personally think Python is
10x better for me, but that's worthless - I also like Rocky Road ice cream
10x more than plain vanilla but who cares?

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

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. This
morning I found another example: for some rather embarrassing
lack-of-communication reasons we actually have the same piece of code
implemented in C++, Java, and Python. It's a small program that accepts as
input an XML file that amounts to a "request" along with some statistical
reporting information. This information is stuffed into a database and
another XML file is returned as a "response" with a bunch of other info.
In all cases 3rd party database and XML libraries were used, so we can
more or less discount those. 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.

-Dave