110 lines
4.8 KiB
Plaintext
110 lines
4.8 KiB
Plaintext
From: markus_kohler at hp.com (Markus Kohler)
|
|
Date: 29 Apr 1999 10:35:50 +0200
|
|
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> <slrn7if4d4.9lh.wtanksle@dolphin.openprojects.net>
|
|
Message-ID: <p54slzn7rt.fsf@bidra241.bbn.hp.com>
|
|
Content-Length: 4434
|
|
X-UID: 1603
|
|
|
|
>>>>> "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
|
|
|
|
|
|
|
|
|