Programming language productivity

Harry George at
Fri May 19 07:15:36 CEST 2006

"malv" <malvert at> writes:

> Once you get involved in larger projects, the dynamic nature of the
> programming tool becomes much more important. I mean by this, the
> ability to stop running code, modify or add to it and continue without
> having to re-establish the state of the program. This may sound trivial
> to many, but in major applications setting up the state again can take
> a considerable processing time. Such feature should be available from
> within the debugging tools.
> In fact, languages like Smalltalk, Lisp and even VB offer this
> possibility.
> Ruby coming up strongly these days also has this dynamic reload
> capability.
> To sum up, I like Python very much but I don't understand how come this
> basic flaw has not been taken care of. It is sufficient to search for
> "reload" to see how many people have struggled with it over the years.
> I hate the idea of having to take up Ruby to really find out how it
> could serve me better in this most critical productivity area.

What is "major project"?  

We have 50 people working on a project, over 5 years, in Python.  Much
of the regresison test can be done by rebuilding context in RAM (no
need to persist).  That is immediate (whole test suite runs in a few
seconds).  Sometimes we have to reestablish context by clearing the
database and then reloading objects from test_input XML files.  That
is slow (perhaps an over night job).  I've yet to experience a context
where language features are the rate limiting step.

On the other hand, I have definitely experienced language as a rate
limiting factor in a) peer code reviews, b) debugging, c) ramping up
new team members.  Python wins those battles everytime.

Harry George
PLM Engineering Architecture

More information about the Python-list mailing list