Python IS slow ! [was] Re: Python too slow for real world

[Markus Kohler]

>>>>> "William" == William Tanksley <wtanksle at dolphin.openprojects.net> writes:

    William> 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?

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

As far as I remember Eiffel requires a global system analysis to be type
safe at compile time. 

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

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

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

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

Agreed. The main problem with todays statically typed languages is that 
they are too restrictive and to complicated. 

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

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

True, SmallEiffel inlines most of the virtual function calls automatically. 
This is the way to go. 

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

Agreed. 

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

The C/C++ compilation model is outdated. Python should *never* adapt that. 

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

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

I'm not sure if I understand this sentence. Do you mean GC is hard to add
to python without breaking existing code ?
I would agree with that. And why do you say "no worry"
Do you mean GC is not worth the effort ?

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

    You may have a look at Strongtalk a Smalltalk with static (optional) type checking.
    Sorry no links, but if a www search does not work I can sent you a document about it. 
   
  Markus
-- 
Markus Kohler  mailto:markus_kohler at hp.com