Is Python overhyped (just like Java)?

[Roy Smith]

"Ajay na" <ajay_637 at hotmail.com> wrote:
> Nope...I'm not trolling...I want someone to give a solid and intelligent 
> argument about why I should switch from C++ to Python!

In general, development time is a lot faster in Python, and execution 
speed is a lot faster in C++.  How much?  Hard to say, but an order of 
magnitide in both cases might not be a bad first guess.

For an amazingly large amount of what most people do, execution speed is 
just not a significant factor.  For an amazingly large amount of what 
most people do, development time is.  Doesn't it make sense to use 
something which is optimized for development time?

Try this.  Count the number of times in the past month your boss has 
asked you, "is it done yet?".  Now, count the number of times he's 
asked, "how come it runs so slow?".  If "is it done yet?" won, you're 
probably a good candidate for Python.

C++ programs also tend to be optimized in the wrong ways.  The low-level 
nature of the language encourages people to worry about low-level stuff 
that saves a few CPU cycles here or there.  At the same time, sea of 
low-level details you have to worry about like memory management and 
const correctness tends to obscure the bigger issues like algorithmic 
complexity.  STL makes some strides towards getting people to use 
efficient algorithms, but it adds a whole layer of complexity of its own.

Python hides all the low-level stuff and lets you concentrate on the 
problem you are trying to solve.  This might even lead to Python apps 
running faster than C++ apps.  In a fixed amount of development time, 
you get to think more about design and algorithms and less about memory 
leaks, dangling pointers, const correctness, and whether you need to 
write a copy constructor or not.

Python is also an interpreted language.  The advantage of this during 
development and debugging are often grossly under-estimated.

I just make a trivial change to a single source file in a project I'm 
working on and times how long it took to run make.  It took 1 minute, 41 
seconds.  The vast majority of that time was make itself, recursing up 
and down the directory tree to discover that nothing else had changed.  
Had the change been to a core header file, I might have been waiting for 
15 minutes while make recompiled the whole world.  With Python, I would 
have been able to test my change in a matter of seconds.

When I'm developing in Python, I'm always firing up an interpreter and 
trying out some code snippet.  It's so fast, it doesn't even break the 
flow of what I was thinking of.  I do it all the time when I can't 
remember what methods a particular object or data type has.  For 
example, I just did:

roy% time python
Python 2.2 (#1, 07/14/02, 23:25:09) 
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> d = {}
>>> dir(d)
['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__', 
'__eq__', '__ge__', '__getattribute__', '__getitem__', '__gt__', 
'__hash__', '__init__', '__iter__', '__le__', '__len__', '__lt__', 
'__ne__', '__new__', '__reduce__', '__repr__', '__setattr__', 
'__setitem__', '__str__', 'clear', 'copy', 'get', 'has_key', 'items', 
'iteritems', 'iterkeys', 'itervalues', 'keys', 'popitem', 'setdefault', 
'update', 'values']
>>> ^D
0.050u 0.090s 0:07.32 1.9%      0+0k 21+2io 0pf+0w

That's 7 seconds to remind myself what methods dictionaries have.  
That's a lot faster than looking it up in a manual (or even on-line).   
Quick, does an STL map<> support equal_range()?  How long will it take 
you to look that up?  I bet it's more than 7 seconds.  These example may 
not sound like much, but they add up when you consider how many times a 
day you do things like this.