Python Productivity over C++

[Alex Martelli]

Steve Mullarkey <stevemul at ozemail.com.au> wrote in message
news:8F4E9C028stevemulozemailcomau at 139.130.250.4...
> I have been a 'C' programmer for the past 15 years and a "C++"
> programmer for the past 3 years. I'm not a genius but would modestly (?)
> class myself as reasonably competent.
>
> In the past week I have become aware of Python. I've bought a book and
> read this newsgroup every day.
>
> I have read in several places productivity claims of 5 to 10 times over
> 'C' and "C++". I would like to ask for some feedback from "C++"
> programmers who have moved to Python as to whether these estimates are
> realistic.

I have not "moved" from C++ to Python: most of my professional
development (what I get paid for) is still C++.  For personal
programming projects, such as my bridge studies, I've moved most
stuff to Python (everything that used to be in Perl, and a good
fraction of what used to be in C or C++).


> In "C++" I have :-
>
> 1. Good tools, Borland C++ Builder, MS VC++, Memory Leak Tools,
> Profilers, Programmers Editor including Class Browser, etc..

My favourite editor has always been vi (now, and since a few years,
in the free gvim version), and it's just as good for Python as it is
for C++.  Otherwise, I find PythonWin and IDLE adequate substitutes
for Microsoft Visual Studio.  ObWarning: I don't do much GUI's, in
either language, so I have no experience of how the GUI builders
compare; Hammond and Robinson's "Python Programming on Win32" seems
to do an adequate job of presenting a huge variety of different
approaches you can use -- if I did have a huge investment in a GUI
builder I'm sure I could keep it (a GUI shell in VB, Delphi, or
whatever you prefer, with most or all of the real work in Python).


> 2. I use the STL (Standard Template Library) which gives powerful string
> and container classes.

I suspect that here we see the usual confusion between STL (the
prototype experimental research thingy which provided inspiration
for what is now in the C++ standard and has since kept changing)
and the Standard C++ Library.  Matters only to pedants like me, I
guess, but one of the little things giving me joy is that I just
barely managed to catch this confusion about to be propagated in
Eckel's otherwise-excellent "Thinking in C++" 2nd edition, and it
was in time to have him correct it (he's such a wonderful writer,
I hope he really gets to grips with the "Thinking in Python" book
he mentions as a possibility!).

Anyway, back to your point 2: Python's dictionaries, lists, and
strings, give you basically all you get from Standard C++'s
containers, and then some.  You may have to do some adaptation
for certain constructs (e.g., remap a std::multimap<> in terms
of a dictionary with lists as entries), and some of the best
features of C++'s <algorithm> are missing (std::next_permutation,
for example), but I notice you don't mention those so I guess
you won't miss them (there is sure to be something around the
net usable as a substitute, anyway:-).


> 3. I use incremental compiling and linking. This reduces wait times to
> very small amounts.
>
> 4. I can also use background compiling and linking.
>
> 5. I have 3rd party libraries to handle Regular Expressions, Date/Time,
> etc..

No compiling and linking at all surely beats even those "very
small amounts", and the good stuff you can find on the net for
Python is a LOT.

> I don't want to start a flame war but, given the above, I just can't see
> where the productivity increase is generated.

For many people, I suspect a key issue is that they never really
understood _100%_ of C++.  It IS a hugely complex language, and
an ENORMOUS investment is needed to fully grasp 90% of it; just
as much effort and expense, to move up to 99%; and as much again,
to get to 99.9%.  I'm about at this last level, so I'm RARELY bitten
by things I just didn't understand perfectly, but I'm unwilling
to do it all over again to get to 99.99% (particularly since, at
this level, existing implementations still deviate substantially
from the Standard).  But I also do consulting and mentoring, and
see presumably-experienced C++ programmers baffled by issues such
as
    MyClass my(5);   // declares a variable
    MyClass mx();    // declares a function, NOT a variable
or
    std::copy(a.begin(), a.end(), b.begin());    // does NOT extend b!
etc, etc, as well as 'deeper' issues such as partial template
specialization, order-of-initialization issues, dominance rules,
the distinctions between overriding, overloading, and hiding, &c.

Judging from my experience, over 90% of "experienced C++ programmers"
have a 90%-or-less grasp of the C++ language.  This is quite
understandable given its complexity and difficulty, but surely
explains why such programmers would be much more productive in
a language that is simple enough that they CAN grasp it well with
much more modest effort (and, mostly, carefully designed so that
not-fully-grasped issues don't rear up and bite you when you
least expect it:-).


However, avoiding C++'s traps and pitfalls is not really where the
big gains came for me, since I'm reasonably well-versed in avoiding
them (and have the scars to prove it:-).  Rather, for me personally
the key issues have to do with Python's intrinsically-dynamic nature.


Exploratory programming, ease of reuse, very easy refactoring, are
three key issues.  In C++, you have to start with a substantially
"right" class structure; you can do minor tweaks, but you can't really
go very far "just playing around with various possibilities"; and when
you see a refactoring would be warranted, it's most often a lot of
work.  Plus, to get any substantial reuse value out of your work, you
have to invest a lot in making it _reusable_ in the first place, or
in reworking it with reusability in mind -- very worthwhile investment,
but still hard to do under production deadlines.  Python's more fluid,
dynamic style helps on all of these fronts: you play around more, get
more possibilities explored, refactor more frequently and effectively,
and get reuse without huge up-front investments in reusability.


> I am genuinely interested
> to ask "C++" programmers :-
>
> 1. What productivity increase do you achieve ?

I've never measured it precisely, but it does lie somewhere
between a factor of 2 and one of 10.  It's probably less for
areas one knows so well (having written a dozen separate programs
or subsystems for them) that one could recode them in one's
sleep, while it tends to the higher end for areas where the
exploratory-programming and refactoring advantages loom large.

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

A couple of weeks (versus a decade of C++, and C before that).
One of the most amazing characteristics of Pythin is how
amazingly FAST one becomes productive with it.


Alex