On Mon, Dec 18, 2006 at 12:02:35PM +0000, Blair Sutton wrote:
: Dear all
: I hope I am sending this to the correct place.
: I regularly use the RAII idiom in Perl 5 and C++ to automatically clean 
: up resources during object destruction.
: I recently read a mail thread "Is RAII possible in Python?" at 
: http://www.thescripts.com/forum/thread25072.html and "Perl vs Python - 
: GC and Reference Counting" at 
: http://discuss.joelonsoftware.com/default.asp?joel.3.323675.32.
: The above threads suggests that Python cannot do RAII since its garbage 
: collection does not offer deterministic finalization. I understand that 
: Parrot will not use reference counting for garbage collection and so may 
: suffer from the same problem. Are my fears warranted?

Short answer: absolutely.

Long answer: emphatically not.  I believe you have a bit of an XY
problem here.  You're wanting transactional security and timely
destruction but have predisposed yourself not to accept them unless
they happen to look like deterministic reference counting.  Perl 6
offers the former without offering you the latter, because Perl 6 must
run on a variety of platforms that may or may not support deterministic
reference counting semantics easily.  Perl 6 is a language, not an
implementation.  As such, it officially Doesn't Care what Parrot does
about GC under the hood.

But the problem goes much deeper than that, and has to do with
the necessary virtualization of time as we scale things up and
distribute responsibility for them.  In this day of multiple,
distributed processing units of uncertain proximity, it's going
to get harder and harder to say what a deterministic reference is.
What if a bit your program is running on a different processor and it
goes down?  You can't know that till the next GC run at the appropriate
granularity fails to sync with the down processor.  A GC solution can
finesse around such problems, up to a point, whereas a deterministic
solution really has only one approach.  In the larger and wider scale
of things, you can't know whether a reference is valid till you try
it--see the Web for an example.  The web would never have take off with
perfect accountability.  (That's why Xanadu didn't work, basically.)

All of computing is getting more like that.

For instance, people are now finding that deterministic locking
solutions don't scale up either.  STM (software transactional memory)
seems to be a way to get around that, and that's partly because a
transactional memory manager can virtualize time much like a garbage
collector can defer decisions it isn't sure of.  Two transactions
can be in conflict in real time, which would prevent at least one
of them from happening under deterministic locking.  But an STM
manager can decide the fate of the transactions based *only* on the
data dependencies, ignoring the bogus realtime dependency, and maybe
decide to allow both transactions if a consistent state is maintained.

In short, programs written in languages that require unnecessary
determinism will not escape the von Neumann bottleneck as easily
as programs written in languages that do not.  Determinism is fine
when you need it, and a good language will provide adequate ways to
express that when you do need it.  (Perl 6 provides several ways that
are much handier than try/finally, and just about as handy as RAII.)
But baking such handicaps into every object merely guarantees it
will not scale well in the real world.  The real world itself avoids
computing deterministically most of the time!  And if anything could
manage determinism, it'd probably be the real world!  Languages that
require determinism will scale only up only when the entire world is
running one huge completely entangled quantum computer.  Determinism
is not interoperable.

Anyway, that's the trend I see.  And that's why Perl 6 has lots of
ways to promise you Don't Care about various dependencies, but Do Care
about others.  That's why Perl 6 has pipes and lazy lists, junctions
and hyperoperators, contend and defer.  These are for building scalable
solutions to run on cell processors and GPUs and clusters of servers
and corporate intranets.  And maybe even trigger a Singularity or two.  :-)


Reply via email to