python simply not scaleable enough for google?

[Vincent Manis]

On 2009-11-11, at 14:31, Alain Ketterlin wrote:
> Terry Reedy <tjreedy at udel.edu> writes:
> 
>> I can imagine a day when code compiled from Python is routinely
>> time-competitive with hand-written C.
> 
> Have a look at
> http://code.google.com/p/unladen-swallow/downloads/detail?name=Unladen_Swallow_PyCon.pdf&can=2&q=
> 
> Slide 6 is impressive. The bottom of slide/page 22 explains why python
> is so slow: in most cases "the program is less dynamic than the
> language".

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. 

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; 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. 

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. 

3. It is certainly true that CPython doesn't scale up to environments where there are a significant number of processors with shared memory. It is also true that similar languages for highly parallel architectures have been produced (Connection Machine Lisp comes to mind). Whether the current work being done on the GIL will resolve this I don't know. Still, even if CPython had to be thrown away completely (something I don't believe is necessary), a high-performance multiprocessor/shared memory implementation could be built, if resources were available. 

4. As to the programming language Python, I've never seen any evidence one way or the other that Python is more or less scalable to large problems than Java. My former employers build huge programs in C++, and there's lots of evidence (most of which I'm NDA'd from repeating) that it's possible to build huge programs in C++, but that they will be horrible :)

-- v