Programming language productivity

[Harry George]

"malv" <malvert at telenet.be> writes:

[snip]
> 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