in reply to Re: Perl losing, unfairly
in thread Perl losing, unfairly
I mailed the author with some issues and have recieved a reply. One part is relevent to what you just said:
i fixed. For example, for % perl -le 'print $ARGV[0]' i take the length of -l print $ARGV[0]
But the fact remains that he has NOT been generous to Perl. In fact the way I read the code hes been ungenerous to perl. Consider all the examples that involve or exit 1 (which is not normal idion to return an error value to the OS in perl, unless that error MUST specifically be 1, any sane programmer would use die,) or the fact that in many of the examples he includes the invocation in the perl examples but not in any of the other examples.
But what really gets me is the File::Find example. His code reads to me the way someone would write it if they deliberately want to disadvantage perl.
use File::Find; find({ no_chdir => 1, wanted => sub { if (($o = $_) =~ s/\.c$/.o/ && -M $_ <= -M $o) { print "compiling $_ to $o\n"; system qw(gcc -c -o), $o, $_; } } }, '.');
Why the no_chdir here, or the options hash at all?
use File::Find; find sub { if (($a = $_) =~ s/\.c$/.o/ && -M $_ <= -M $a) { print "compiling $_ to $a\n"; system qw(gcc -c -o), $a, $_; } }, '.';
So, by my reading of this once these changes are made Perl wins.
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^3: Perl losing, unfairly
by dreadpiratepeter (Priest) on Jun 16, 2004 at 12:57 UTC | |
by demerphq (Chancellor) on Jun 16, 2004 at 13:01 UTC | |
by PodMaster (Abbot) on Jun 16, 2004 at 13:09 UTC | |
by dreadpiratepeter (Priest) on Jun 16, 2004 at 13:14 UTC |