python simply not scaleable enough for google?
vmanis at telus.net
Sat Nov 14 09:20:13 CET 2009
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,
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
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
> 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
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.
More information about the Python-list