From: wtanksle at dolphin.openprojects.net (William Tanksley)
Date: Wed, 28 Apr 1999 22:54:30 GMT
Subject: Python IS slow ! [was] Re: Python too slow for real world
References: <613145F79272D211914B0020AFF6401914DAD8@gandalf.digicool.com> 	<p5g15lmb35.fsf@bidra241.bbn.hp.com> <slrn7ieipq.8uk.wtanksle@dolphin.openprojects.net> <372769B0.3CE8C0F3@prescod.net>
Message-ID: <slrn7if4d4.9lh.wtanksle@dolphin.openprojects.net>
Content-Length: 2994
X-UID: 1586                                                  

On Wed, 28 Apr 1999 20:04:00 GMT, Paul Prescod wrote:
>William Tanksley wrote:

>> And Oberon (SlimBinaries), and Eiffel (typing and general compile-time
>> error catching), and ...

>Actually, isn't Eiffel's type system famous for being full of holes?

I'm familiar with the covariance/contravariance argument, but I've never
before heard anyone say anything about Eiffel being full of holes.  What
problems have you heard of?

>Regardless, wouldn't a better source of inspiration on typing be a
>language with *optional* compile-time error checking?

Good question.  I don't know the answer, but I can point out the dangers
of not planning our path.

One dangerous side of allowing flexibility is that we could be like C++,
where the safe way of doing anything requires more typing and often causes
incompatibilities.  Examples range from virtual functions; through inline
functions, templates, single-root object hierarchy, and garbage
collection; to covariance/contravariance.

The other dangerous side, of course, is being one of the languages which
are so safe you can't use them without a huge manual and pages of UML.
Python can NOT wind up like this, regardless of the dangers obvious in the
other side.

Let me expand a little on the dangers of C++.

 - virtual functions.  It shouldn't be my job to tell the compiler when
virtual lookups are the only thing to do; the compiler ought to be able to
tell.  For performance gurus, a way to hint to the compiler that virtual
lookups were _not_ needed might be useful -- but what if the programmer
was wrong?

 - inline functions.  Again, a good compiler HAS to make this decision for
itself, and in a good compiler, whether or not this decision was made
should be transparent to the programmer.

 - templates.  Generic functions are a very good thing, and with Python
2's type support we might wind up needing them.  In C++, templates are
also a very good thing, but thanks to the C model of seperate compilation,
no two C++ compilers handle templates compatibly.

 - single-root object hierarchy -- this is a must when the default binding
is virtual.

 - GC -- hard to add after the fact.  No worry with Python, but what if
there are other issues like it?

 - covariance/contravariance/"no"variance -- when a subclass redefines a
function, what types of input parameters can the redefinition accept?  In
C++, you can't accept a different type without overloading the function.
With covariance (in Sather) you can allow the redefined function to accept
a parent class, which allows the new function to handle more subclasses
(including all the ones the old function handled).  With contravariance
you can require the redefinition to be more specific, accepting fewer
classes.  Aside from my obvious dislike of novariance, I'm not going to
take sides ;-).

> Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself

-- 
-William "Billy" Tanksley
"But you shall not escape my iambics."
           -- Gaius Valerius Catullus




