>I'm not Dan, but I have the impression that Java will really take off
>because the WWW is such a huge success. From what I gather, Netscape,
>who dominates the WWW scene, is working with Sun on future WWW based
>products. I would guess that Java is the language they will use as
>the base language. Right now, about 60% of the browsers out there are
>NetScape and the number is climbing. So, in the future, if the number
>of browsers out there that uses Java as the base agent language is 70%
>(a guess based on the combined strength of Netscape and Sun), then not
>many people are going to have access to all those cool Python
>agents/programs unless Python compiles to JavaVM (assuming that the
>browsers will accept programs/applets/agents or
>whatever-they-will-be-call in compiled form). . .
Well, I looked at the Java Web page and it seemed I couldn't do
anything interesting there because I needed Java (free for my own use,
fork out big bucks otherwise) to do anything. If Sun's plan is to
sell all WWW providers a Java license and have every WWW browser
running Java, I doubt this will take off (although I'm not sure I have
my facts completely straight -- I gave up after about 5 minutes -- hey,
I'm a busy guy).
In my blissful ignorance I see two problems with compiling to JavaVM:
1) Licensing.
2) I'm dubious as to whether JavaVM can be interfaced nicely
to C extensions to python, particularly if it uses a different
memory management scheme. If we can't use Python C extensions
then all we've got is "brain dead python" and who cares?
(For the same reason I don't think Stallman's vision of Python
compiling to Scheme will ever materialize either.)
>I think many of the ideas in S. Majewski's WWW page should be
>considered now for future versions of Python. First, reference
>counting should be eliminated in favor of garbage collection which
>sets the anchor to other enhancements.
Someone please jump in and point out that I'm being stupid, if I am.
(I'm no expert on this.)
One of the really nice things about Python is that it peacefully
coexists with C libraries with very few complications. For example,
a C library can keep a pointer to a Python object, with no extra
overhead (such as registering the pointer in a table somewhere),
and there will be no problems whatsoever so long as the refcount
was incremented correctly. Now, under a more intrusive GC strategy
such pointers must be either disallowed, or they must be registered
with the garbage collector, so that when the collector decides to
move the object, it will know to change the pointer too. Bug city. Yuck.
Also, I imagine, the heap space would need to be managed in some complicated
way so that the C libraries can have "normal" heap behavior and python
can have fancy garbage collection. If the scheme is to run fast, this
might involve using system dependant features on different platforms,
making portability much more complicated, no?
The main problems I see with the current scheme are
1) once in a while circular references are useful (eg, for TkInter)
2) the law of entropy suggests that if a Python process is active
enough for long enough the memory will eventually grow to an
arbitrary size with lots of tiny objects evenly distributed therein.
These are a concern, but please don't throw out portability and ease
of extension to solve them. Other than that I don't understand your
assertion that GC would be the "anchor to other enhancements".
Please explain. -a.
=====
If you feel like being cruel, ask a 6 year old if he can
count to 1000. Then ask him to prove it.
Unfortunately the really smart ones will pull the
"one, two, skip a few, a thousand"
trick. This is irritating, but it ABSOLUTELY DOES
NOT JUSTIFY VIOLENCE!