large-scale app development in python?

[John J. Lee]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:

> jjl at pobox.com (John J. Lee) writes:
> > I've never checked: how many LOC is Zope?
> 
> I don't remember but the answer has been posted here before.
> 
> > Of course, one has to remember that lower LOC (by a multiple of 5 or
> > so, according to some experienced C++, Java and Python developers
> > here) is one of the very reasons that people choose Python in the
> > first place, so some sort of correction has to be applied, or a more
> > sophisticated metric used.
> 
> No, LOC is not perfect but IMO it's about as indicative as most
> anything else I can think of.  No correction factor should be applied.

Well, patently, whether that's true or not ("No correction factor
should be applied.") depends ENTIRELY on the question at hand!

So, we're in agreement, I'm sure -- we're just asking different
questions -- but just to state the obvious:

If the question is "what problems does development of a program with x
many LOC cause", one should not apply any correction factor, because
one suspects the problems are more directly dependent on LOC than on
language choice per se.  That's to say, to a poor first approximation,
choice of language determines the required resources only through the
mechanism of determining the LOC required.

If the question is "what resources are required to develop a program
that solves (a problem whose size, when expressed in Java, is x LOC)"
-- which is the question relevant to the OP's question -- and one is
using LOC as a measure of cost, then one should apply a correction
factor.  Hmm, you know you're writing bad English when you have to
parenthesize to indicate precedence :-/ The situation is no different,
of course, in the case where the project goals may grow or shrink
depending on how programmer-efficient the language is.


> It could be that a 100 KLOC Python program does more stuff than a
> comparably sized Java program, but that doesn't mean the Python
> program is bigger.

Sure, in terms of the problems it causes.  Equally clearly, in terms
of the problems it *solves*, the Python program is "bigger" (in that
particular sense -- let's not get into an empty debate over
definitions).


> I think Zope is in the 100 KLOC range within a factor of some small
> integer.  A large application these days may mean 10 MLOC or more.

You're right.  But of course, the *reason* we're all worried about
large programs is that we want to know "how do I solve problem x with
minimum use of resources", or "given these resources, what problems
can I solve".  We're not trying to write big programs, we're trying to
solve big problems.


John