Programming language productivity
harry.g.george at boeing.com
Fri May 19 07:15:36 CEST 2006
"malv" <malvert at telenet.be> 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
> Ruby coming up strongly these days also has this dynamic reload
> 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.
PLM Engineering Architecture
More information about the Python-list