Python development time is faster.

Harry George at
Mon Nov 13 15:49:54 CET 2006

"Chris Brat" <chrisBrat at> writes:

> I've seen a few posts, columns and articles which state that one of the
> advantages of Python is that code can be developed x times faster than
> languages such as <<Insert popular language name here>>.
> Does anyone have any comments on that statement from personal
> experience?
> How is this comparison measured?
> Thanks
> Chris

Personal experience takes two forms.

1. Broad experience with languages, such that doing a single project
   in a new language gives a sense of the relative power and
   ease-of-use.  Everyone I know who is a strong Python supporter took
   that route.  There was an Ahh-Ha experience part way into the first
   project.  This includes folks who could charitably be called
   curmudgeons, and people who are truely fluent in, say, C++ or Lisp.

   For these people the main success factor is that "it just works".
   You spend time on new functionality, or experimenting with
   alternative algorithms, not on debugging.  Of course, we work in a
   regression-test-driven world, so we don't pile up a lot of untested
   code and then hope for the best.  Python facilitates that
   test-early-test-often approach with its modularity and fast
   edit-run cycle.

2. Write the same thing in 2 or more languages.  Due to machine
   migrations and project redirections I have done that with
   perl-and-python, java-and-python, modula3-and-python,
   lisp-and-python.  In all cases, python was the second language, so
   there is some learning curve to be adjusted for (i.e., I understood
   the semantics better).  However, since I've done some
   perl-and-perl, and lisp-and-lisp, I can maybe make that adjustment.

   The result was that python was relatively faster-to-develop.  I
   can't give a specific speedup factor, but I sure can say Python is
   now my default language.  The success factors were:

   a) Once you get the hang of the language (a weekend?), you can
   write without reference to the manuals.  Or if you do reference, it
   is a quick lookup.  No struggling to figure out how to code
   something.  Or to decypher what a line of code actually does.

   b) The project doesn't bog down as you add features.  The language
   can accomodate new paradigms, patterns, or major functionality.  If
   you do need to refactor, that is easy too.  

   c) Peer code reviews are easy -- both you and the reviewers can
   understand the code's intent at a glance.

Harry George
PLM Engineering Architecture

More information about the Python-list mailing list