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