python simply not scaleable enough for google?

[Alf P. Steinbach]

* Rami Chowdhury:
> On Thu, 12 Nov 2009 12:02:11 -0800, Alf P. Steinbach <alfps at start.no> 
> wrote:
>> I think that was in the part you *snipped* here. Just fill in the 
>> mentioned qualifications and weasel words.
> 
> OK, sure. I don't think they're weasel words, because I find them 
> useful, but I think I see where you're coming from.
> 
>> Specifically, I reacted to the statement that <<it is sheer nonsense 
>> to talk about "the" speed of an implementation>>, made in response to 
>> someone upthread, in the context of Google finding CPython overall too 
>> slow.
> 
> IIRC it was "the speed of a language" that was asserted to be nonsense, 
> wasn't it?

Yes, upthread.

It's sort of hilarious. <g>

   Alain Ketterlin:
       "slide/page 22 explains why python is so slow"

   Vincent Manis (response):
       "Python is a programming language; it is implementations that have speed
       or lack thereof"

This was step 1 of trying to be more precise than the concept warranted.

Then Steven D'Aprano chimed in, adding even more precision:

   Steven D'Aprano (further down response stack):
       "it is sheer nonsense to talk about "the" speed of an implementation"

So no, it's not a language that is slow, it's of course only concrete 
implementations that may have slowness flavoring. And no, not really, they 
don't, because it's just particular aspects of any given implementation that may 
exhibit slowness in certain contexts. And expanding on that trend, later in the 
thread the observation was made that no, not really that either, it's just (if 
it is at all) at this particular point in time, what about the future? Let's be 
precise! Can't have that vague touchy-feely impression about a /language/ being 
slow corrupting the souls of readers.

Hip hurray, Google's observation annuled, by the injections of /precision/. :-)


> Which IMO is fair -- a physicist friend of mine works with a 
> C++ interpreter which is relatively sluggish, but that doesn't mean C++ 
> is slow...

Actually, although C++ has the potential for being really really fast (and some 
C++ programs are), the amount of work you have to add to realize the potential 
can be staggering. This is most clearly evidenced by C++'s standard iostreams, 
which have the potential of being much much faster than C FILE i/o (in 
particular Dietmar Kuhl made such an implementation), but where the complexity 
of and the guidance offered by the "design" is such that nearly all extant 
implementations are painfully slow, even compared to C FILE. So, we generally 
talk about iostreams being slow, knowing full well what we mean and that fast 
implementations are theoretically possible (as evidenced by Dietmar's)  --  but 
"fast" and "slow" are in-practice terms, and so what matters is in-practice, 
like, how does your compiler's iostreams implementation hold up.


Cheers,

- Alf