Python Productivity over C++

Courageous jkraska1 at san.rr.com
Fri Jun 9 11:08:49 EDT 2000


> > First off, any claim of an order of magnitude increase in productivity is
> > pure nonsense. See Brooks for an explanation or Boehms and McConnell for
> > hard data.
> 
> That's likely true. I do suspect there are more anecdotal examples of
> "I did the same project in Python and I finished in half the time!" compared
> to C++ than the other way around, but these aren't very scientific.

I've used C++ since 1985. Recent experiences with C++, Lisp, Java, and
Python all have me favoring Python for productivity. Is there an order
of magnitude increase in producitivity? Well base 2 maybe. :)

> >>2. How long did you use Python before you achieved increased
> >>productivity ?

About 2 weeks.
 
> > Up to now, I've been using C++ for scripting. I'm not proficient in Python
> > yet, so writing a Python script takes far longer than writing a C++ utility
> > and the Python code itself is larger than the equivalent C++ code.

It only takes about 2 weeks become proficient in Python.

> But then you must be very good at C++. :) (Hi Wim!) My experience was that I
> was faster than C++ after a couple of days already. Note that I haven't had
> any real experience with post-STL C++, which may or may not matter.

Stl? *S*tl? Could it be?!?!?! Satan!!! :^)

> It's perhaps just a difference in philosophies as well; C++ is a statically
> typed language and its proponents put a lot of emphasis on this kind of
> correctness. In Python you might come up with lots of correctness rules
> as well, but people don't, as the whole approach is different. People
> rarely care about things like public/private, even. This also means a lack
> of getters/setters in many cases; those will only be created if they
> are deemed necessary. This means encapsulation can be broken easily,
> but Python programmers don't care about this so much -- in practice often
> it is more of a problem to strictly preserve encapsulation (and type safety)
> than it is to fix any problems when and if they arise.

This flexibility of approach allows someone to concentrate more
on the problem domain and less on their language, IMO.


C/



More information about the Python-list mailing list