PLEAC project

Alex Martelli aleax at aleax.it
Thu Aug 16 12:00:19 EDT 2001


"Oleg Broytmann" <phd at phd.pp.ru> wrote in message
news:mailman.997952546.30621.python-list at python.org...
    ...
> "If successful, this project may become a primary resource for quick,
> handy, and free solutions to most common programming problems using
> higher-level programming languages. It could also be useful for comparison
> on ease-of-use and power/efficiency of these languages."

I dispute this, given FAQ number 6 at
http://pleac.sourceforge.net/pleac-faq.html

It gives a Ruby example, but basically it boils down to: since
Perl automatically initializes unbound variables, and "it is
-very- important" that PLEAC snippets do just the same as the
Perl Cookbook snippets, then it's not acceptable to use the
various languages in the normal way -- presumably (not spelled
out, but what else could it mean?) *every* variable being used,
e.g. in Ruby or Python, needs a try/except (in Python's terms)
to simulate Perl's "convenient" 'auto-initialization'.

I wonder how they manage that in Haskell, since I can't think
of a way to get uninitialized variables' use past the compiler,
but that's a pretty idle curiosity on my part.  The key issue
is that if and when they produce a zillion recipes that, rather
than using the various languages as they're meant to be used,
strive to contort them enough to mimic Perl's peculiar and
allegedly 'convenient' semantics, they won't have a zillion
useful recipes for each language, but rather a zillion horrors.

A _useful_ translation of the Perl Cookbook needs to address
each language's specific strengths and issues, like the
Python Cookbook up on Activestate's site is doing -- e.g.
in Ruby or Python you're not MEANT to use unbound variables,
and the try/except to catch that error is typically placed
at a much higher level on the callchain than the individual
recipe/snippet is addressing.  (In Haskell, the compiler
ensures that you won't be using unbound variables:-).

I'm gonna keep posting to the Activestate's Python Cookbook,
although anybody's welcome to take the recipes I've posted
(some of them explicitly address the same issues as some of
the Perl Cookbook's ones, and the discussion part mentions
this) and PLEAC'ize them as far as I'm concerned (I'm not
sure if by posting those recipes to the Python Cookbook I've
lost the right to authorize such derived works, though --
IANAL nor do I play one on the net), but I most assuredly
won't be PLEAC'izing them myself.


Alex






More information about the Python-list mailing list