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
--
http://mail.python.org/mailman/listinfo/python-list
