python simply not scaleable enough for google?

[Alf P. Steinbach]

* 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'?

:-)

You're piling up so extremely many fallacies in one go that I just quoted it all.

Anyways, it's a good example of focusing on irrelevant and meaningless precision 
plus at the same time utilizing imprecision, higgedly-piggedly as it suits one's 
argument. Mixing hard precise logic with imprecise concepts and confound e.g. 
universal quantification with existential quantification, for best effect 
several times in the same sentence. Like the old Very Hard Logic + imprecision 
adage: "we must do something. this is something. ergo, we must do this".

It's just idiocy.

But fun.


Cheers & hth.,

- Alf