python simply not scaleable enough for google?

[Vincent Manis]

On 2009-11-13, at 23:39, Robert Brown wrote, quoting me:
> Common Lisp blends together features of previous Lisps, which were designed to
> be executed efficiently.  Operating systems were written in these variants.
> Execution speed was important.  The Common Lisp standardization committee
> included people who were concerned about performance on C-optimized hardware.
Guy L Steele, Jr., `Common Lisp The Language' 1/e (1984). p. 1 `COMMON LISP 
is intended to meet these goals: Commonality [...] Portability [...] Consistency
[...] Expressiveness [...] Compatibility [...] Efficiency [...] Power [...]
Stability [...]' The elided text amplifies each of the points. I repeat: the 
purpose of Common Lisp was to have a standard Lisp dialect; efficiency was 
less of an issue for those investigators. 

As for C-optimized hardware, well, the dialects it aims to be compatible with
are ZetaLisp (Symbolics Lisp Machine), MacLisp (PDP-10), and Interlisp (PDP-10, 
originally). 

CLtL mentions S-1 Lisp as its exemplar of high numerical performance. Unfortunately, 
S-1 Lisp, written by Richard Gabriel and Rod Brooks was never finished. MacLisp was
a highly efficient implementation, as I've mentioned. I worked at BBN at the time
Interlisp flourished; it was many things, some of them quite wonderful, but efficiency
was NOT its goal. 

> The Scheme standard has gone through many revisions.  I think we're up to
> version 6 at this point.  The people working on it are concerned about
> performance.  
Yes, they are. You should see <a>'s rants about how <b> specified certain 
features so they'd be efficient on his implementation. I had real people's 
names there, but I deleted them in the interests of not fanning flamewar 
flames. 

> For instance, see the discussions about whether the order of
> evaluating function arguments should be specified.  
That was a long time ago, and had as much if not more to do with making
arguments work the same as let forms as it had to do with efficiency. 
But I'll point out that the big feature of Scheme is continuations, and 
it took quite a few years after the first Scheme implementations came out
to make continuations stop being horrendously *IN*efficient. 

> You can't point to Rabbit (1978 ?) as
> representative of the Scheme programming community over the last few decades.
I didn't. I used it to buttress YOUR argument that Schemers have always been
concerned with performance. 

>> Using Python 3 annotations, one can imagine a Python compiler that does the
>> appropriate thing (shown in the comments) with the following code.
> I can imagine a lot too, but we're talking about Python as it's specified
> *today*.  The Python language as it's specified today is hard to execute
> quickly.  Not impossible, but very hard, which is why we don't see fast Python
> systems.

Python 3 annotations exist. Check the Python 3 Language Reference. 

I notice you've weakened your claim. Now we're down to `hard to execute 
quickly'. That I would agree with you on, in that building an efficient 
Python system would be a lot of work. However, my claim is that that work 
is engineering, not research: most of the bits and pieces of how to implement
Python reasonably efficiently are known and in the public literature. And 
that has been my claim since the beginning.

-- v