149 lines
5.9 KiB
Plaintext
149 lines
5.9 KiB
Plaintext
From: wtanksle at dolphin.openprojects.net (William Tanksley)
|
|
Date: Thu, 29 Apr 1999 23:06:15 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> <slrn7if4d4.9lh.wtanksle@dolphin.openprojects.net> <p54slzn7rt.fsf@bidra241.bbn.hp.com>
|
|
Message-ID: <slrn7ihpf4.dk7.wtanksle@dolphin.openprojects.net>
|
|
Content-Length: 5450
|
|
X-UID: 259
|
|
|
|
On 29 Apr 1999 10:35:50 +0200, Markus Kohler wrote:
|
|
>>>>>> "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.
|
|
|
|
According to Meyer, that would be the most permissive thing to do. He
|
|
also suggested an option, the rule about "no polymorphic CATcalls", which
|
|
would not require such intensive processing and would allow most of the
|
|
same things.
|
|
|
|
All in all, though, after having read over Meyer's materials very
|
|
carefully, I have to say that I don't like his justifications. I just
|
|
looked at the Sather site (Sather is an Eiffel-inspired language which
|
|
uses contravariance), and they explain how to solve the problem he was
|
|
demonstrating (in a MUCH more logical and reuable way!).
|
|
|
|
Since Sather is itself an subclass of Eiffel, I don't think I'm violating
|
|
any typing rules by claiming that imitating Sather is similar to taking
|
|
things from Eiffel ;-).
|
|
|
|
Sather itself offers some interesting options for inheritance. For
|
|
example (let me translate to Python):
|
|
|
|
class Gizmo(Object):
|
|
|
|
inherits the interface of Object, but _none_ of its implementation. If
|
|
you want the same member functions as Object had, you have to do this:
|
|
|
|
class Gizmo(Object):
|
|
import Object
|
|
from Object import new, del, etc
|
|
|
|
This means that classes can behave like modules (because they bring
|
|
functions into their namespace the same way)... And logically, vice
|
|
versa.
|
|
|
|
Of course, "inheriting an interface" is only meaningful with static
|
|
typing. Notice that this also addresses the issue of interfaces -- every
|
|
class is an interface.
|
|
|
|
The disturbing thing, of course, is that this is totally incompatible with
|
|
the current way of doing things. That's easy to overcome, though:
|
|
|
|
class Gizmo(Object, <Doodad>):
|
|
from Doodad import *
|
|
|
|
> >> 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.
|
|
|
|
[the dangers of C++ and other loose languages -- mixed measures considered
|
|
harmful]
|
|
|
|
> 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.
|
|
|
|
I'm not sure that they're _too_ restrictive; they work in their domains.
|
|
The problem is that we don't want to loose Python's greatest strength:
|
|
it's friendly.
|
|
|
|
> 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.
|
|
|
|
Inlines virtual functions? I think you got your wires crossed ;-).
|
|
Virtual functions, by definition, can't be inlined. Inlining is where you
|
|
place the routine's source code directly into the code of the calling
|
|
routine.
|
|
|
|
> 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 ?
|
|
|
|
Guido seems to think so. Anyone who disagrees is free to contribute and
|
|
work on porting GC code (I would like to see it).
|
|
|
|
I think that worrying about the other issues is FAR more rewarding -- RC
|
|
is not only hard to replace with GC, but the rewards for doing so are
|
|
relatively small (in comparison to the other things we can think about).
|
|
|
|
I don't want to stop anyone from trying, though. The nice thing about
|
|
free software is that even if everyone disagrees with you or thinks it's
|
|
not worth it you can still get it done.
|
|
|
|
So what other issues are worth thinking about? I don't know.
|
|
|
|
> You may have a look at Strongtalk a Smalltalk with static (optional)
|
|
> type checking.
|
|
|
|
Found it using Google.com (a GOOD search engine for technical matters).
|
|
http://java.sun.com/people/gbracha/nwst.html
|
|
|
|
I'll be spending some time reading it. My initial impression: _very_
|
|
good. This would fit well, I think.
|
|
|
|
> Markus
|
|
|
|
--
|
|
-William "Billy" Tanksley
|
|
"But you shall not escape my iambics."
|
|
-- Gaius Valerius Catullus
|
|
|
|
|
|
|
|
|