python simply not scaleable enough for google?

[Vincent Manis]

On 2009-11-13, at 22:51, Alf P. Steinbach wrote:
> It's sort of hilarious. <g>
It really is, see below. 

> 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.
Because `language is slow' is meaningless. 

An earlier post of mine listed four examples where the common wisdom was `XXX is slow' and yet where that 
turned out not to be the case.

Some others. 

1. I once owned a Commodore 64. I got Waterloo Pascal for it. I timed the execution of some program 
(this was 25 years ago, I forget what the program did) at 1 second per statement. Therefore: `Pascal 
is slow'. 

2. Bell Labs produced a fine programming language called Snobol 4. It was slow. But some folks at 
IIT in Chicago did their own implementation, Spitbol, which was fast and completely compatible. 
Presto: Snobol 4 was slow, but then it became fast. 

3. If you write the following statements in Fortran IV (the last version of Fortran I learned)

   DO 10 I=1, 1000000
     DO 10 J=1, 1000000
       A(I, J) = 0.0
10 CONTINUE

you would paralyze early virtual memory systems, because Fortran IV defined arrays to be stored 
in column major order, and the result was extreme thrashing. Many programmers did not realize 
this, and would naturally write code like that. Fortran cognoscenti would interchange the two 
DO statements and thus convert Fortran from being a slow language to being a fast one. 

4. When Sun released the original Java system, programs ran very slowly, and everybody said 
`I will not use Java, it is a slow language'. Then Sun improved their JVM, and other organizations 
wrote their own JVMs which were fast. Therefore Java became a fast language. 

> 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.
OK, let me work this one out. Because most iostreams implementations are very slow, C++ is a slow 
language. But since Kuhl did a high-performance implementation, he made C++ into a fast language. 
But since most people don't use his iostreams implementation, C++ is a slow language again, except
for organizations that have banned iostreams (as my previous employers did) because it's too slow, 
therefore C++ is a fast language. 

Being imprecise is so much fun! I should write my programs this imprecisely. 

More seriously, when someone says `xxx is a slow language', the only thing they can possibly mean 
is `there is no implementation in existence, and no likelihood of an implementation being possible, 
that is efficient enough to solve my problem in the required time' or perhaps `I must write peculiar
code in order to get programs to run in the specified time; writing code in the way the language seems
to encourage produces programs that are too slow'. This is a very sweeping statement, and at the very
least ought to be accompanied by some kind of proof. If Python is indeed a slow language, then Unladen 
Swallow and pypy, and many other projects, are wastes of time, and should not be continued. 

Again, this doesn't have anything to do with features of an implementation that are slow or fast. 
The only criterion that makes sense is `do programs run with the required performance if written 
in the way the language's inventors encourage'. Most implementations of every language have a nook 
or two where things get embarrassingly slow; the question is `are most programs unacceptably slow'. 

But, hey, if we are ok with being imprecise, let's go for it. Instead of saying `slow' and `fast',
why not say `good' and `bad'?

-- v