* Rami Chowdhury:
On Thu, 12 Nov 2009 12:02:11 -0800, Alf P. Steinbach <al...@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
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to