Python vs. Perl, which is better to learn?

[Alex Martelli]

On Saturday 25 May 2002 19:43, Kragen Sitaker wrote:
> The following message is a courtesy copy of an article
> that has been posted to comp.lang.python as well.

I think I haven't been posting or even following c.l.py for a couple
of weeks, what between trips and book editing, so it's funny to see
this appear in my mailbox out of the blue (no idea of when I wrote
the original to which you're now replying).  Still, as you seem to be
under very serious misconceptions, I'll take time to try and help...:

> Alex Martelli <aleax at aleax.it> writes:
> > Find-matching-paren makes short work of that.  If anything, the
> > problems with refactoring in C++ or Java come from their horrid
> > choice of leaving this / self *IMPLICIT* -- so a reference to
> > any name X may or may not mean self.X / this->X and the poor
> > editor can hardly help you with THAT as you move code between
> > classes (or, in C++, from in-class to out-of-class)...
>
> I don't see why the editor can't help you with that --- it's
> statically decidable.

Sorry to pollute this NG with C++ code, but it's apparently needed
to help Kragen see.  Consider a simple example:

template <class X>
class Y: public X {
    public:
        int foo() { return x; }
};

struct A {
int x;
};

int x = 45;

struct B {
};

Y<A> ay;
Y<B> by;

#include <stdio.h>

int main()
{
    ay.x = 23;
    printf("%d %d\n", ay.foo(), by.foo());
    return 0;
}


Now, as you're editing this, how is it "statically decidable"
whether the 'x' mentioned in the template is this->x or a
global -- when it's either in two almost identical uses of
the same template in adjacent lines?!

Of course, the preprocessor allows even more such horrors,
but, as you see, you don't need any preprocessor for the
problem to appear -- a little pure C++ amply suffices.


Java's a bit better because it's more restrictive and poorer --
no preprocessor, no templates, and so on.  However, it's
perfectly legal Java to import with a * from a package, AND
inherit from a class, which are not yet defined or not accessible
to the editor _as you are editing_.  They'll have to be defined
later before you can compile, but, whatever gave you the
impression that code being edited is constrained to be compilable
*at each stage it passes through while you're editing it*?!  There
is fortunately no such constraint -- and therefore, the editor
cannot generally know if a reference to 'X' comes from the
as-yet-unknown base class, or from a *-imported package.

Again, therefore, the horrid design choice of leaving this-> / self.
implicit bites.


Alex