Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

phaylon (6115)

phaylon
  {rs} {at} {474.at}
http://474.at/

Journal of phaylon (6115)

Friday September 28, 2007
09:35 AM

My take on the Perl vs. Python code

[ #34560 ]

A small follow up to chromatic

I'm always amazed that people who don't write Perl try to compare their Perl code to their $favorite_language code. I sometimes have a really hard time not writing a satirical essay where I try to write Python (where I have zero experience) and compare it to my Perl (which I write for a living).

Since the original author just threw together examples of what he doesn't like about Perl in a mostly non-consistent manner it isn't really an example and it doesn't make sense to me to try to translate it 1:1.

So, anyway, here's my take on the corrected version (I have left out the stuff that wouldn't compile):

# this simple line prevents globals in a
# file-wide scope. Might not be that nice, but if
# you're having problems with _that_, you should
# probably focus more on the problem you're
# actually trying to solve.
use strict;

sub func {
    my ($x, $array) = @_;

    # this must be as YUCK in Perl as in Python,
    # since they are doing the same thing.
    $array->[0] = 4;
    # UPDATE: I think I just got it. The original
    # author seems to complain that arrays aren't
    # references _by_default_ in Perl. Since you
    # can just use [] and therefor have the choice
    # in Perl (but not in Python as it seems),
    # this is IMO one more point for Perl.

    # this too works in Perl as in Python. A fact
    # that the original author obviously didn't
    # like, so he just wrote ++$x.
    $x += 1;

    print "$x\n";
    return 1;
}

my $i      = 1;
my $newvar = 'abc';
my @array  = (1, 2);

# this is another thing I don't get. Passing the
# array by reference in Perl is ugly, but it's
# fine in Python?
my $x = func(1, \@array);

print "$newvar\n";
print "i = $i\n";

$array[1] = 0;

# the original author seems to think here it
# should be that print $x, $y; should join the
# two with a whitespace. Well, I don't. We have
# the rather nice
print "@array\n"; # prints 4 0

I want to close with the notion that I would actually be interested in looking into a bit of Ruby and Python. But I feel the community supporting a language is important, if not more important than the language itself (Otherwise I'd be writing Scheme until you couldn't read the parenthesis on my keyboard anymore). And I really, really don't like what I see in the Ruby and the Python communities. While one might (correctly) argue that the core communities probably are more mature, they aren't that loud and it just seems too unprofessional to me.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

My take on the Perl vs. Python code 9 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • He is mostly just complaining about the syntax. So, he is saying that:

    ${$arrayRef}[0]=4;

    Is uglier than (I agree):

    array[0]=4;

    And

    $x=func(1,\@array);

    Is uglier than (meh):

    x=func(1,array)

    Reference handling is one of the few things I really don't like about Perl. In a high level language like Perl, you shouldn't have to worry about what's a reference what isn't (most of the time). It goes against DWIM.

    He also complains about having to change the prefix on the array to access the individual element.

    • Honestly, I don't see a problem with the references. You can always write $foo->[3] to dereference the array. And I really don't agree that references and non-references should be interchangable. Since non-refs and refs behave differently, you _have_ to differentiate them. Otherwise this would just scream "action at a distance" to me.

      I can however, understand why non-Perl people have problems with the changing sigils. Because they aren't used to it. Personally, I like it, but I can see why it was decid

      --
      Ordinary morality is for ordinary people. -- Aleister Crowley
      • Yeah, it seems like most Lanuage A is better than Lanuage B arguments are really just Lanauge B is different from what I'm used to.

        • Exactly :) That's why I bow before those people who try to transform those silly discussions into "I like $x about $y" and "I hate $x about $y" thoughts. Those are the rants and raves everybody can learn something from. Especially if they are written by people who actually work with that language of course :)

          --
          Ordinary morality is for ordinary people. -- Aleister Crowley
      • Well, when it comes to dereferencing syntax this isn't a problem:

        my @names = keys %$name_age;
        but this is clearly uglier than it should be:

        my @names = keys %{$self->name_age};
        especially when combined with other curly constructs.

        • What’s really annoying is that there’s not even any reason for the prototype on keys (nor, really, on most other functions). Even if keys $foo will blow up at compile time, keys %$foo won’t – but that doesn’t mean the reference is a hash ref. The only reason for keys to have a prototype is because of how the parser works; a mere artefact.

          Context-sensitive sigils worked for Perl 4 because it doesn’t have references; in Perl 5 they are a pointless wart.

    •     $x=func(1,\@array);
      ...
          x=func(1,array)

      I like that you have to specify that you're passing a reference. I like that by default, perl flattens arrays into the argument list. I seem to do that more often than passing in references. When I was playing with Ruby, a gotcha for me was that you had to add extra syntax to flatten the array in an argument list. So what are these people complaining about? You gotta have it one way or the other, I like the perl way, but I could adjust to t

      • Besides, you could say:

        $x = func(1, @array);

        sub func {
        my ( $x, @array ) = @_;
        ...
        }
        You only get into trouble this way if you want to pass in more than one array or hash.
        • Though I forgot one of the points of this whole thread was about passing by reference...oh well. I hardly ever want to do that anyway except in OO programming. And in perl, objects are always references.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.