Python isn't necessarily slow

Siegfried Gonzi siegfried.gonzi at kfunigraz.ac.at
Tue Mar 5 05:38:01 EST 2002


Ronny Wichers Schreur wrote:
> 
> Siegfried Gonzi wrote (in comp.lang.python):
> 
> > After my nightmare using Clean [..] [Clean] is a useless big
> > pile of shit! [..] Clean's array-type-system is an impudent
> > scandal for its own
> 
> As one of the Clean developers, I'm sorry to read that you're
> frustrated with our language.

There is more to say.
> 
> I believe that you should use the right tools for the right
> job. This depends on the job, but also on your own preference.
> Judging from your comments you seem more at ease with a language
> that's not statically typed and that doesn't enforce referential
> transparency.

A)
No, No, No. This isn't about statically typed languages; at least not
what I mean. Type checking is a tool, what I have written many times,
which helps one produce readable code. The problem in Clean: the array
concept is not a tool which helps a programmer it impedes the
programmer. The problem is not that an array has a type the problem in
Clean actually is that it is impossible often to judge what is allowed
and what not. I started hating Clean when I had completed my program for
a 2 dimensional Kriging interpolation. The code worked, but when I
augmented it, it just behaved different, e.g. it was immediately not
possible to assign  a row in a calculation (but just before it *was*
possible). I then had to copy the results back to the array via
list/array-comprehension.

B)
Clean does often not work correctly. Look at my code which I have posted
in comp.lang.python. Sometimes the code failed and the count_lines
routine does not work. Last year I wrote some programs in Clean in order
to translate some files:

12:03:2001,12:23:23,3.344,45.556,..

to the fractional part of the year. I had to translate about 50
stations. Sometimes the Clean function worked for that station sometimes
not. Often I was forced to copy one content of a file to a file where
just before the Clean version worked. And I had used then this file to
translate "the other file". Btw.: I had downloaded the file-directory
module, but at this time it was corrupted and I had always to restart
the Clean program in every directory of the station (this was
cumbersome).

C) 
I wrote a program for a German colleague which reads in some numbers
from a file and does perform some calculations. The version worked on
the Mac but it only *sometimes* worked correctly on NT/XP/2000!
Sometimes the first result was a wrong number, but sometimes not. And in
turn I have just rewritten the version in C in order to deliver a
program to a colleague. It was impossible to correct the Clean version.
What should one do when it sometimes behave correct but sometimes not.

CC) I am not sure whether I fooled myself or not: but reading a number
from a console-command-line does not work. I had to use a readline and
then get rid of the whitespaces. This was cumbersome.

D)
Last year I wrote some programs in order to calculate some
summary-statistics: Mean, Median, Min, Max,..

It was impossible to augment the code. I wanted to augment it with the
skewness but the compiler complaint (I would have to re-start the
program to get the special compiler message, but I can send you the
program if you like). It was not possible to add the calculation for the
skewness. Maybe there were too many variables in a function (this was my
guess at this time). I have used the R-language then to calculate the
statistics.
 
D)
And the worst matter: There is no way to write numbers with a specific
precision to a file. Fabian T.'s library just does not always work as
expected.


Point D is my greatest crtisim on Clean and the array concept. I really
miss types but not as Clean demonstrates it.

> Maybe Python with NumPy is the right choice for your job and
[...]
> Happy hacking.

Thank your for your kind mail. I didn't contact any Clean developers,
because still I think all there are kind guys which are working hard,
but I am not sure anymore that they discern what people complain
about.Surely, there a peoples who are not contented with the
license-scheme (and open source); and others expect this; and others
this; and others that. 

But shouldn't the following trigger the sirens: Did you observe that the
user community is shrinking and shrinking and shrinking? 

I have to repeat myself: types are not my problem. If Clean hadn't
performed as it had I would have never contemplated to throw it away.

Regards,
S. Gonzi



More information about the Python-list mailing list