Is Python overhyped (just like Java)?

Bryan belred1 at yahoo.com
Sat Mar 29 20:28:33 EST 2003


i have a real world example of this.  at my company, we had a project that
was done in c++.  it was basically server socket code, xml parsing, string
manipulation, redundant lookup tables, and file I/O.   the engineer who
worked on it left the company.   the engineer who took it over didn't know a
bit a python.  he learned python in about a weekend.  and rewrote the entire
project in python plus added more features than the c++ version had it done
in about 1 week and polished/optimized in another week.  the end result was
about 1/10 the size.  all the complexity was gone.  as for speed...  the c++
version processed 10,000 entries in about 2 seconds.  the python one is
about 3 seconds.  for this particular project that one second difference per
10,000 records is completely lost in the noise.    we are having this same
kind of excellent results in other projects too.  so,  from my own personal
experience and others around me, the increased productivity with less
complexity you get from python over c++ is mind-boggling.

bryan


"Alex Martelli" <aleax at aleax.it> wrote in message
news:omqha.31133$Jg1.677484 at news1.tin.it...
> 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.
>
>
> > Those who use Python know they are sacrificing a lot in terms of memory
> > and
> > speed.  But if they took the same attitude toward C++, they can actually
> > get a lot of flexibility, code reuse, simplicity, and all the other
> > benefits of
> > OO programming at over half the cost of using Python!  The problem is
that
>
> Whaddya mean "over half the cost"?
>
> I'm putting the final touches on a talk I'll give to PythonUK next
> week (it's held together with the ACCU conference) on "Python for
> C++ and Java programmers".  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.
>
> 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.
>
> But what won't change is, the Python program IS smaller, because
> Python it's a higher-level language -- AND each statement is
> intrinsically cleaner and simpler, so the development time ratio,
> for programmers who have perfectly mastered both languages and
> the respective standard libraries, is even more extreme than the
> ratio in program sizes.  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.  For tasks to which Python is
> extremely well suited (text processing of all kinds, including XML
> parsing, for example), you may ALSO get better running time than
> C++ with the standard library would give you -- in general, C++
> lets you develop faster code, but oh what a price in terms of
> productivity you pay for that!
>
> And the funniest thing is, there IS no need to pay that price --
> 90% of your program's runtime is likely to be taken up by 10%
> of your program's source code, or some such ratio.  By writing
> Python first, you'll often get an application with acceptable
> performance; if not, you profile it, find out the hot-spots,
> optimize those in Python terms, and if that's still not enough,
> it's EASY to recode the hot-spots in faster ways while still
> leaving MOST of your application in Python.  There are many
> ways to do such recoding (even without counting the still
> experimental 'psyco' selective just-in-time optimizer), and
> among them are ways to integrate C++, such as SciPy's "weave"
> 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).
>
> > 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...!), 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.
>
>
> > Nope...I'm not trolling...I want someone to give a solid and intelligent
> > argument about why I should switch from C++ to Python!
>
> You shouldn't *SWITCH*!  If you hadn't already made the huge
> investment to master all the complexity of C++, it might be
> best to avoid it -- but, if you HAVE made it, count it as a
> "sunk cost", as I do, and see how best to leverage it.  Learn
> Python (a trivial investment compared to learning C++), and
> use BOTH Python and C++ in your development.  You'll find that
> Python gives you extremely high productivity and flexibility,
> letting you prototype, experiment, refactor whole architectures
> from the inside out and back again -- even if you knew the
> final product MUST be delivered in C++ due to contractual
> requirements, you'd STILL be better off doing the early phases
> in Python ANYWAY.  Once the program is working, benchmark it;
> most often, you'll find you're done -- in a FRACTION of the
> time.  If the performance isn't satisfactory, profile it, and
> start optimizing -- including recoding parts in C++, e.g.
> with weave or the Boost Python Library.  In the end, you'll use
> both Python and C++ in the same program, *each for what it does
> best*: Python for most of the code, C++ for the bottlenecks.
> It's as simple as this, really!
>
> And your programming productivity will soar...
>
>
> Alex
>






More information about the Python-list mailing list