Python Productivity over C++

[Ken Seehof]

Steve Mullarkey wrote:

> <snip>

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

I look forward to some nice tools under development.  Right now, I'd say
that overall C++ tools are better than the python tools (aat least in the
Windows environment).  On the other hand, imho, python doesn't need the
tools as much.

GUI building tools - C++ wins.  Until Boa Constructor arrives.  There's also
PythonWorks, which I haven't looked at.

Memory leak tools - Python doesn't need them (except for circular refs which
aren't that tough anyway).  Python wins here.  The next major release of
python will probably have true garbage collection, which will remove orphan
circular refs.

Profilers - Never looked, so I don't know if python has any good ones.  If
I'm concerned with saving a few milliseconds, I code an extension.

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

Having strings and container classes as built-in types with language syntax
is a big advantage for python.  I find that while STL is perhaps as
/powerful/ as python's set built-in types, it still takes me longer to code
with it, and my code is much less readable than it would be in python.

> 3. I use incremental compiling and linking. This reduces wait times to
> very small amounts.

True, but to me this isn't as nice as having an interactive interpreter.
Suppose you write a function to manipulate a list in some way.  Now you want
to test it.  In python, you call the function from the interpreter, perhaps
expressing the list as a literal.  In C++ you write a test function, maybe
complete with some user interface code, debug your test function, compile
(very quickly with your incremental compiler) and run your test function,
and then try to figure out whether your bug is in the function being tested
or your test function.  Anyway, I find that the typical write-test-debug
cycle goes much faster in an interpreter, and with less distraction.

BTW, seems to me that in theory one could write a C++ interpreter.  The idea
would be to make the compiler available through a library function that
would compile the one-liner into a (very small) shared library, link to it,
and call it.  Does anyone know it that has been done?

> 4. I can also use background compiling and linking.
>
> 5. I have 3rd party libraries to handle Regular Expressions, Date/Time,
> etc..
>
> I don't want to start a flame war but, given the above, I just can't see
> where the productivity increase is generated. I am genuinely interested
> to ask "C++" programmers :-
>
> 1. What productivity increase do you achieve ?

Very hard to measure.  I think maybe 4 to 1, but I can't prove it.

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

I could match my C++ within a couple weeks.  Maybe a couple months to get to
4-1, mostly because I had to look for new libraries.

> Best regards,
>
> Steve Mullarkey.
> Tascom Pty Ltd.
> Berry, NSW 2535, Australia.
> Tel : (61)-(2)-4464-3328

Where does it come from?

The interpreter certainly helps, but that's not really the main thing.

When I code in C++ or python, I spend most of my time testing and debugging,
so the question is: How does python save time on debugging?

In C++ most persistent bugs are related to memory and type issues.  Python
handles memory for you, and gives less potential for type related problems
(despite the nonsense about C++ being safer because of static type checking
(oops, I hope I didn't just start a flame war :-) ).  So most of these bugs
don't appear in the first place.

I find that the Visual C++ debugger is better than the python debugger
(though eventually someone will write a really awesome python debugger,
which should be relatively easy given python's introspective capabilities).
However, I find that in the two years I've been programming with python, I
use the debugger less often than when I'm programming with C++ (which I've
been doing for about twelve years).

Python bugs are usually much easier than C++ bugs.  Write down a brief
description of the next ten significant bugs you encounter in C++ and you
will see what I mean.

Dealing with types in C++ is often very time consuming.  C++ has a vast
number of redundant basic types that various people have wrapped and aliased
in various ways.  By basic types I mean integers, floats, lists, strings,
and mappings (ok, I'm being python-centered here).  In C++ I find myself
spending more time making sure I have the right kind of integer, or
converting from one string type to another, or figuring out how to iterate a
particular kind of list, etc.  In python, if someone invents a new sequence
type, or implements a special kind of mapping object, I immediately know how
to use it with no guessing or reading manuals.  The STL certainly helps C++
overcome this, but STL was invented long after C++, so you still have to
deal with the multitude of types.  Python's containers were there from day
1.

The learning curve for third party libraries is a major factor in
productivity.  In python it is often said that there is one obvious way to
do a thing.  As a result, it is usually easy to remember (or even guess)
correct usage.  You never have to ask, "Is that supposed to be an unsigned
short int or a long int?", or "Is that a const char *, a char const *, or a
MegaWidgetString& ?", or "Am I supposed to delete that?".

I like to write my own custom programming tools (whether in C++ or python),
especially for large projects.  Python programming tools are easier to write
because of it's dynamic nature, and because string processing is easier.

Why is string processing easier in python?  Python doesn't have more string
processing capability but python can do the same things with much less
syntactical messiness.  There is no need for a string class to wrap the
basic type.  And then there's the handy slice operators that are
syntactically cleaner than anything you can get in C++.  A regex library is
a regex library, but it sure is nice to test your regular expression on the
command line (perhaps 10 seconds per test rather than 20-30 seconds with a
C++ compiler).

I don't have anything against C++, but for me, the role of C++ is changing.
It is becoming what assembly used to be when I was programming with C: a way
to code that inner loop that has to go really fast.

--
Ken Seehof
kens at sightreader.com
starship.python.net/crew/seehof
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kens.vcf
Type: text/x-vcard
Size: 343 bytes
Desc: Card for Ken Seehof
URL: <http://mail.python.org/pipermail/python-list/attachments/20000613/8f553a61/attachment.vcf>