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.
Is uglier than (I agree):${$arrayRef}[0]=4;
Andarray[0]=4;
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.x=func(1,array)
Re:Syntax
phaylon on 2007-09-28T15:31:05
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 decided to be changed.
It just seems to me that he's complaining that Perl has a different syntax than Python. He can of course do that, but when he starts saying this is why Python is better, it gets ridiculous. I won't even start ranting about the thousands of years old problem that people think they are themselves a statistical majority
:) Re:Syntax
stu42j on 2007-09-28T15:39:53
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.Re:Syntax
phaylon on 2007-09-28T15:48:39
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 :) Dereferencing (was: Syntax)
jplindstrom on 2007-10-01T10:48:19
Well, when it comes to dereferencing syntax this isn't a problem:but this is clearly uglier than it should be:my @names = keys %$name_age;especially when combined with other curly constructs.my @names = keys %{$self->name_age};Re:Dereferencing (was: Syntax)
Aristotle on 2007-10-03T07:23:54
What’s really annoying is that there’s not even any reason for the prototype on
keys(nor, really, on most other functions). Even ifkeys $foowill blow up at compile time,keys %$foowon’t – but that doesn’t mean the reference is a hash ref. The only reason forkeysto 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.
Re:Syntax
runrig on 2007-09-28T16:29:43
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 the other way (WITHOUT COMPLAINT!).$x=func(1,\@array);
...
x=func(1,array)Re:Syntax
runrig on 2007-09-28T16:31:45
Besides, you could say:You only get into trouble this way if you want to pass in more than one array or hash.$x = func(1, @array);
sub func {
my ( $x, @array ) = @_;
...
}Re:Syntax
runrig on 2007-09-28T16:34:23
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.