81 lines
3.4 KiB
Plaintext
81 lines
3.4 KiB
Plaintext
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
|
|
|
|
|
|
|
|
|