Is Python overhyped (just like Java)?

David Abrahams dave at boost-consulting.com
Mon Mar 31 23:47:11 CEST 2003


Alex Martelli <aleax at aleax.it> writes:

> Ajay na wrote:
>
>> Can some-one please explain why one would want to use Python?
>
> One word: *PRODUCTIVITY*.
>
>> What is wrong with C++?
>
> One word: *COMPLEXITY*.
>
>
>> In my opinion, the problem with C++ has nothing to with the language
>> semantics.  The problem is that when people are confronted with a
>> powerful language like C++, they tend to want to optimize everything
>> to death.  That's when they get themselves in trouble.
>
> You're over-generalizing.  Not all users of C++ are so naive as to
> have failed to read Knuth -- "Premature optimization is the root of
> all evil in programming".  But the point is -- by choosing a lower
> level language, like C++, at the start of your project, rather than a
> higher level one, like Python, you ARE optimizing WAY prematurely.

In my experience, it may be even more powerful to begin with hybrid
development from the ground up.  On one project, when I tried to start
with Python and push time-critical code into C++, I found that
although algorithm prototyping had been fast, the Python interface I
had developed for those critical components was not well-suited to the
C++ world.  In my application it was easy to predict where the bulk of
the time would be spent, and had I written the core engine in C++
early on I might have saved myself a redesign effort.  That may not
apply everywhere, though.  Another nice effect of this approach is
that you end up with a well-designed core C++ library that can be used
by C++-only applications, instead of something that really only works
well with a Python wrapper.

> One example I give is a task for which C++ is quite suited, with its
> standard library -- reading a text file, breaking it into
> whitespace-separated 'words', building an index from each word to
> the line numbers on which it appears, and showing the index with
> words in alphabetical order, one per line, each followed by the line
> numbers on which it appears.

Boy, that sure sounds like a job for Python to me.  Something like
"high-performance linear algebra with sparse matrices" sounds more
like a job for which C++ is "quite suited".

> Thanks to the excellent support given for these tasks by the standard
> library, the C++ source is ONLY twice as big as the Python source for
> the same job (a more usual ratio is around 5:1).  This holds for both
> the simplest versions, and the slightly more complicated ones with
> somewhat better optimization.  The runtimes on my box (Linux Mandrake
> 9.0, gcc 3.1, Python 2.3) are, when the programs are run on the 4.4 MB
> of the "King James Bible" in plain ASCII text: 17.4 seconds for the
> simplest C++, going down to 15 with optimizations; 11.2 seconds for
> the simplest Python, going down to 8.1 with optimizations (CPU times
> are in very similar ratios).  Of course, this basically reflects the
> excellence of Python's intrinsics (dictionaries, lists, strings)
> versus the lesser quality of C++'s library implementation (maps,
> vectors, strings) -- with different implementations, you may see
> different ratios.

Really?  Are you sure that time wasn't sunk into I/O?  "Read all the
lines from a file" is a primitive in Python, but not in C++.

Also, it's only fair to point out that C++ doesn't have one library
implementation -- each compiler comes with its own.  Which
implementation(s) were you testing?  Oh, I see it was probably
libstdc++ that comes with gcc 3.1.  Well, IIRC GCC-3.1 was well known
to optimize poorly (it took them some time to figure out how to
integrate all the new optimizations that came in with GCC-3, and they
actually made things slower for a while), and I wouldn't exactly say
that libstdc++ is the fastest implementation.

In other words, there's nothing intrinsic about C++ which says that it
has to be twice as slow as Python at this job.  I don't think it's
fair to talk about "the lesser quality of C++'s library
implementation."

Aren't you glad I'm asking these questions now, instead of at your
talk in Oxford? ;-)

<snip>

> The simplest and most flexible C++ you can write is still way
> bigger, more complicated, and less flexible than the most refined
> and optimized Python code it may make sense to write -- it's as
> simple as this.  

I think when you're comparing the use of the core language I have to
agree.  However, when it comes to functionality provided by libraries,
it really depends on the quality and availability of the library
interface.  That said, I think Python probably still has many more
useful libraries than C++ does.

<snip>

> and the Boost Python Library (if you don't know Boost, DO give it a
> look -- it WILL increase your C++ productivity, and not just by
> easing integration of C++ to Python, either).

Thanks :-)

>> people who don't understand C++, are afraid to use the 'virtual'
>> features of that language because it's 'too expensive'.  But that's
>> stupid...because Python's 'virtualness' is even more expensive!
>
> It's quite inconsiderate of you to imply that Python users are
> "people who don't understand C++", when among those users are people
> like Andrew Koenig (author of "Ruminations on C++" and other great
> C++ books, as well as a towering figure of C++ development -- the
> algorithm for name lookup in the C++ language is called "Koenig
> lookup" because HE developed it...!), 

Actually, Andrew resists being associated with that particular
feature, as I found out at the last committee meeting.  IIRC, he said
that he had little if anything to do with it, and wasn't sure why
people put his name on it.  Some might consider that association to be
undesirable (http://www.boost-consulting.com/writing/qn.html).

...but that doesn't change the enormity of Andrew's contribution to
the C++ language and community.

> Bruce Eckel (author of best-sellers "Thinking in C++" and "Thinking
> in Java"), and so many others whose C++ competence is in all
> likelihood AT LEAST as good as yours.

Yeah; what Alex said.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




More information about the Python-list mailing list