python simply not scaleable enough for google?

[Steven D'Aprano]

On Wed, 11 Nov 2009 16:38:50 -0800, Vincent Manis wrote:

> I'm having some trouble understanding this thread. My comments aren't
> directed at Terry's or Alain's comments, but at the thread overall.
> 
> 1. The statement `Python is slow' doesn't make any sense to me. Python
> is a programming language; it is implementations that have speed or lack
> thereof.

Of course you are right, but in common usage, "Python" refers to CPython, 
and in fact since all the common (and possibly uncommon) implementations 
of Python are as slow or slower than CPython, it's not an unreasonable 
short-hand.

But of course "slow" is relative. And many applications are bound by I/O 
time, not CPU time.


> 2. A skilled programmer could build an implementation that compiled
> Python code into Common Lisp or Scheme code, and then used a
> high-performance Common Lisp compiler such as SBCL, or a
> high-performance Scheme compiler such as Chez Scheme, to produce quite
> fast code; 

Unless you can demonstrate this, it's all theoretical. And probably not 
as straight-forward as you think:

http://codespeak.net/pypy/dist/pypy/doc/faq.html#id29


> Python's object model is such that this can be accomplished
> (and not using CLOS); a Smalltalk-80-style method cache can be used to
> get good method dispatch. This whole approach would be a bad idea,
> because the compile times would be dreadful, but I use this example as
> an existence proof that Python implementations can generate reasonably
> efficient executable programs.

I think a better existence proof is implementations that *actually* 
exist, not theoretical ones. There's good work happening with Psycho and 
PyPy, and you can write C extensions using almost-Python code with Cython 
and Pyrex.

There's very little reason why Python *applications* have to be slow, 
unless the application itself is inherently slow.


> In the Lisp world, optional declarations and flow analysis are used to
> tell the compiler the types of various variables. Python 3's annotations
> could be used for this purpose as well. This doesn't impact the learner
> (or even the casual programmer) for who efficiency is not that
> important.
> 
> Unladen Swallow's JIT approach is, IMHO, better than this; my point here
> is that we don't know what the speed limits of Python implementations
> might be, and therefore, again, we don't know the limits of performance
> scalability.

Absolutely. It's early days for Python.



-- 
Steven