Python vs. C++ Builder - speed of development

Alex Martelli aleax at aleax.it
Wed Jan 29 13:18:29 CET 2003


Brandon Van Every wrote:
> Laura Creighton wrote:
   ...
>> That is because almost
>> all my time spent in C++ come from some other place than actually
>> writing code from scratch.  Other people's milage may vary.

My own C++ experience was about 50-50 between "writing my own code"
(both "from scratch" and as changes to things I had previously
written) and helping colleagues with their code.  Both tasks are
somewhat onerous with C++, though the second is even more so.

> Find a different job then.

I have -- mostly, with the company Laura co-founded, AB Strakt -- so
I can now code just about exclusively in Python, thanks be.  So what?

That doesn't mean I shouldn't feel the pain of people who cannot yet
do so, and see if I can't help them enhance their quality of life by
doing more Pyton and less C++ (I'm not as extreme as Laura in claiming
the ideal quantity of C++ in the mix is zero: I'd guesstimate
"somewhere between 0 and 20%" depending on application area &c).
Human solidarity, an engineer's appreciation for using the RIGHT
tools, and an amateur economist's love of productivity increases
anywhere in the economy, all push me towards offering such help.

> Are you getting paid well for your C++
> headaches?  I wouldn't put up with it if it's as onerous as you make it
> sound.  Unless the money is really really good.

As Laura indicated, in her case you could probably use at least THREE 
repetitions of "really"... in mine, just one "really" would be enough.

But, it only matters up to a point, particularly in the context of
this thread's subject.  Hourly cost to hire a top-notch C++ or Python
programmer isn't all that different.  The point is, rather, that for
Python coding you can expect higher productivity by a factor of, say,
two to ten; maintenance productivity is similar.

Other phases of software development also benefit, although to lesser
degrees and depending on using appropriate methodological approaches --
e.g., having iterative analysis and design based on rapid feedback 
cycles with the customer (or whoevers stands for the customer) lets 
you do faster and better design and analysis with Python, while 
"waterfall" development would be just as much of a disaster in any 
language, just about.


Alex





More information about the Python-list mailing list