Re: large-scale app development in python?

Discussion in 'Python' started by John Roth, Aug 23, 2003.

  1. John Roth

    John Roth Guest

    "gabor" <> wrote in message
    news:...
    > hi,
    >
    > at the company where i'm working we have to rewrite a part of our
    > java-based application in a different language.
    >
    > there were many options, at the end python and c++ remained.
    >
    > our program is quite big, so c++ was an obvious choice.
    >
    > python remained because we have to finish the rewrite in a reasonable
    > time, and python has all the necessary libraries or bindings that we
    > need.
    >
    > but i got a question, that i couldn't answer:
    > -you can't compile python, as you can c++ or java => there's no type
    > checking before starting the program => if one programmer changes a
    > method name or method signature, then how do we know we changed all the
    > code that calls that method?
    >
    > how do you solve these kind of problems? i know that unit tests are a
    > good thing, but i don't know if they can help in this situation?


    Generally, if you follow the TDD methodology, that is, your test suite has
    complete coverage and you test with every small change, you'll find
    out during coding that you forgot to change something. The trick is to
    have complete statement coverage, which is something that TDD does
    as a matter of course.

    If you've got sloppy programmers, and you don't have an automated
    test suite with close to complete coverage, or you don't run those tests
    after every change, you're going to have problems.

    > are there any people who wrote a big program in python? how did they
    > handle these problems?


    There are quite a few large programs in Python. Zope comes to mind
    immediately.


    >
    > or python simply isn't suited to write bigger (more complex) apps?
    >
    > thanks,
    > gabor


    John Roth
     
    John Roth, Aug 23, 2003
    #1
    1. Advertising

  2. John Roth

    Paul Rubin Guest

    "John Roth" <> writes:
    > There are quite a few large programs in Python. Zope comes to mind
    > immediately.


    I think by the standards of "large programs", Zope would be considered
    medium sized.
     
    Paul Rubin, Aug 23, 2003
    #2
    1. Advertising

  3. John Roth

    John J. Lee Guest

    Paul Rubin <http://> writes:

    > "John Roth" <> writes:
    > > There are quite a few large programs in Python. Zope comes to mind
    > > immediately.

    >
    > I think by the standards of "large programs", Zope would be considered
    > medium sized.


    I've never checked: how many LOC is Zope?

    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.


    John
     
    John J. Lee, Aug 24, 2003
    #3
  4. John Roth

    Paul Rubin Guest

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

    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.
     
    Paul Rubin, Aug 24, 2003
    #4
  5. John Roth

    John J. Lee Guest

    Paul Rubin <http://> writes:

    > (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
     
    John J. Lee, Aug 24, 2003
    #5
  6. John Roth

    John J. Lee Guest

    Paul Rubin <http://> writes:

    > (John J. Lee) writes:
    > > > 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.

    >
    > I'm not sure I agree with that. Programming tasks follow Parkinson's
    > law just like anything else: they expand to fill the available
    > resources. That's why Microsoft Word now takes hundreds of megabytes
    > to install and run, and will keep expanding because more resources
    > keep getting thrown at it.
    >
    > In more normal situations, infinite resources aren't available, and
    > programs reach a kind of stasis where they do about as much as
    > possible while staying maintainable. So an organization developing in
    > Python instead of Java won't get a smaller program that's cheaper to
    > maintain. They'll get a comparably sized program that does more.


    I don't think you actually read my post, because you're just repeating
    what I said there -- thereby contradicting the post of yours I was
    replying to. Enough! -- I give up on this thread.


    John
     
    John J. Lee, Aug 25, 2003
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul Rubin
    Replies:
    0
    Views:
    362
    Paul Rubin
    Aug 23, 2003
  2. Dave Brueck
    Replies:
    1
    Views:
    299
    Cameron Laird
    Aug 24, 2003
  3. limor
    Replies:
    9
    Views:
    523
    A. Lloyd Flanagan
    Apr 23, 2004
  4. Andrea Griffini
    Replies:
    46
    Views:
    1,169
    Jack Diederich
    Oct 24, 2004
  5. Frohnhofer, James
    Replies:
    3
    Views:
    344
    R Baumann
    Oct 19, 2004
Loading...

Share This Page