python simply not scaleable enough for google?

J Kenneth King james at agentultra.com
Tue Nov 17 11:42:44 EST 2009


David Cournapeau <cournape at gmail.com> writes:

> On Tue, Nov 17, 2009 at 10:48 PM, Aaron Watters <aaron.watters at gmail.com> wrote:
>>
>>> I don't think Python and Go address the same set of programmer
>>> desires.  For example, Go has a static type system.  Some programmers
>>> find static type systems to be useless or undesirable.  Others find
>>> them extremely helpful and want to use them them.  If you're a
>>> programmer who wants a static type system, you'll probably prefer Go
>>> to Python, and vice versa.  That has nothing to do with implementation
>>> speed or development expenditures.  If Google spent a million dollars
>>> adding static types to Python, it wouldn't be Python any more.
>>
>> ... and I still have an issue with the whole "Python is slow"
>> meme.  The reason NASA doesn't build a faster Python is because
>> Python *when augmented with FORTRAN libraries that have been
>> tested and optimized for decades and are worth billions of dollars
>> and don't need to be rewritten* is very fast.
>
> It is a bit odd to dismiss "python is slow" by saying that you can
> extend it with fortran. One of the most significant point of python
> IMO is its readability, even for people not familiar with it, and
> that's important when doing scientific work. Relying on a lot of
> compiled libraries goes against it.
>
> I think that python with its scientific extensions is a fantastic
> tool, but I would certainly not mind if it were ten times faster. In
> particular, the significant cost of function calls makes it quickly
> unusable for code which cannot be easily "vectorized" - we have to
> resort to using C, etc... to circumvent this ATM.
>
> Another point which has not been mentioned much, maybe because it is
> obvious: it seems that it is possible to makes high level languages
> quite fast, but doing so while keeping memory usage low is very
> difficult. Incidentally, the same tradeoff appears when working with
> vectorized code in numpy/scipy.

I think this is the only interesting point in the whole conversation so
far.

It is possible for highly dynamic languages to be optimized, compiled,
and run really fast.

The recent versions of SBCL can compile Common Lisp into really fast and
efficient binaries.  And Lisp could be considered even more dynamic than
Python (but that is debateable and I have very little evidence... so
grain of salt on that statement).  It's possible, it just hasn't been
done yet.

PyPy is getting there, but development is slow and they could probably
use a hand.  Instead of waiting on the sidelines for a company to back
PyPy developemnt, the passionate Python programmers worth a salt that
care about Python development should contribute at least a patch or two.

The bigger problem though is probably attention span.  A lot of
developers today are more apt to simply try the next new language than
to roll of their sleeves and think deeply enough to improve the tools
they're already invested in.

>
> David



More information about the Python-list mailing list