Python Productivity over C++

[Frank V. Castellucci]

Before you peruse this response please understand that I am not
advocating C++ over Python. I am having a tremendously educational and
productive time using Python. My responses are in regards to C++
comments which I feel are either not true, or that the arguments being
presented are based on a subjective desire, or lack thereof, to achieve
the functionality expressed as lacking or inferior.

Christian Tanzer wrote:
> 
> "Frank V. Castellucci" <frankc at colconsulting.com> wrote:
> 
> > > There are lots of reasons. The ones first springing to my mind are:
> > >
> > > - The tools you mention notwithstanding, C++ still forces you to write
> > >   lots of low-level code by hand (e.g., memory management, the
> > >   `orthodox canonical class form').
> > >
> > > - C++ doesn't offer any means of meta-programming. If you want to add
> > >   some mechanism (like serialization, introspection, ...) to a class
> > >   hierarchy, you'll have to add member functions to every class in the
> > >   hierarchy. In Python you can implement the complete mechanism in the
> > >   root class of the hierarchy.
> >
> > This is crap:
> >
> > 1. There are gc, SmartPointer, heap management, etc. class libraries out
> > there.
> 
> Guess what. Something like SmartPointer was one of the first classes I
> implemented. In C++, that doesn't relieve you of thinking about memory
> management, though.

This is kind of funny because in my experience memory management
thinking usually precludes SmartPointer implementation.

> 
> > 2. There is the type information in standard conforming compilers.
> 
> Nowadays, there is.

Agreed, but the language had the ability for you to write your own, or
use someone else's library which provided the same.
 
> RTTI doesn't offer any mechanisms remotely approaching Python features
> like `__getattr__'/`__setattr__' though. Not to speak of `eval' and
> `exec'.
> 
> > 3. There is, has been, and will be more, C++ class Class libraries which
> > are powerful, easy to use, and free. I was using NIHs Class class about
> > 5 years ago.
> 
> So what? Your pains start as soon as you want to combine libraries
> from different sources which happen to use incompatible idioms (like
> overloading global operators, ...).

Every language has a painful aspect to itself. Some take more time to
correct than others.

> I've used C++ and Python for projects of comparable size/complexity
> and based my statements on that experience.
> 
> That's not scientific research, and of course it depends on my style
> of using the two languages.
> 
> Your experience might be different.

I try not to pick a language for implementation until I am happy that
problem space is adequately defined, a reasonable degree of requirement
specification have been put forth, a sound analysis and design has been
done, and a language is available which satisfies the solution space. As
a contract developer this time alloted to perform these tasks may span
from one weekend by myself to many months with teams of people.
Sometimes the people who hire me decide the language before these steps.
I do the best I can.

Hands down, a interpretive language with a reasonably rich functional
capability will allow someone to "be more productive" than one which
requires intervening steps to get you into the unit test/debug cycle. I
don't go for the "one language cures all" position personally because if
it were true, we wouldn't have so many to choose from.

When any language has been around for awhile and supported through
developers like you and I by ADDING capability that the native grammar
ALLOWS us to, then the language becomes useful. Python is useful.
 
-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package