* Sean Conner <[email protected]> [2006-12-22 22:45]:
> It was thus said that the Great A. Pagaltzis once stated:
> > * Sean Conner <[email protected]> [2006-12-22 21:35]:
> > > But *neolithic code*?
> >
> > Yeah.
> >
> > > What? I should do
> > >
> > > map
> > > {
> > > open INPUT $_;
> > > &do_some_process;
> > > close INPUT;
> > > } @ARGV;
> >
> > Almost. You can do it that way if you prefer it, but in cases
> > such as this one I'd write it like so:
> >
> > for ( @ARGV ) {
> > # ...
> > }
>
> Ah, the Bronze Age code (more on this in a bit).
>
> > Or you can call it `foreach` if you like that better.
> > Independently of that, if you don't like the `$_`, you can
> > name a variable explicitly:
> >
> > foreach my $file ( @ARGV ) {
> > # and use $file here
> > }
> >
> > There is never a good reason to use `for(;;)` in Perl. If you
> > need to iterate over indices, you do it this way:
> >
> > for my $i ( 0 .. $#ARGV ) {
> > # ... and use $ARGV[ $i ] here
> > }
> >
> > As a side effect, you get to lose the `<` vs `<=` source of
> > off-by-one errors.
>
> I think this makes Peter daSilva's argument about Perl and it's
> "There Is More Than One Way To Do It" paradigm. Let's see ...
>
> for ( <init> ; <cond> ; <incr> )
>
> for ( <max-count> )
There is no such thing.
> for <var> ( <lower-bound> .. <upper-bound> )
>
> No wonder it's taking so long for Perl 6 to come out---the
> parser alone must be horribly complex to disambiguate all these
> constructs (and from other messages, the Parl 6 parser is even
> *more* complex).
No, it is trivial to disambiguate. It's either `for( expr )` or
`for( expr; expr; expr )`, which you can tell apart by the
semicolons.
And anyway, in Perl 6, `for(;;)` and `foreach(LIST)` have
different names, so they're not ambiguous in the first place.
The reason Perl 6 is so late has little to do with the complexity
or not of its grammar.
> Anyway, the bit about your code being the Bronze Age.
>
> If the way I do it is neolithic, your's isn't much better. It
> still implies an order to the operations, whereas map doesn't
> have that restriction and the code can be parallelized easier,
> and thus is a more modern way of programming, especially given
> the rise of multicore processors in even home PCs.
In Perl 5, map isn't and never will be parallelised, so this is
a pretty hypothetical point. Nor is there anything about the
`for(LIST)` construct per se that implies an order, such that
it couldn't be defined to be parallelised if map was.
> > But there is relatvely rarely even a need to index into an array.
> > Most of the time you just want to either iterate over the whole
> > thing or push/pop/shift/unshift elements. Makes code easier to
> > read, too, and reduces coupling even at the most local scales.
>
> Perhaps for what you do. I just checked some Perl code I wrote
> and I hit specific spots in multiple arrays and can't see a way
> around that (LOG refers to a webserver log file):
I did say "relatively rarely", no? I didn't say "never".
> while(<LOG>)
> {
> my @entry = m/$c_parse_apache/o;
> my $size = @entry;
>
> if ($size)
> {
> $g_hits++;
> $g_transfer += $entry[LOG_BYTES] unless $entry[LOG_BYTES] eq "-";
>
> $g_hits[$entry[LOG_STATUS] / 100]++;
>
> &sort_entry(@entry);
> }
> }
>
> If you have a better way of coding this, I'm all ears (in fact,
> if you want the entire script, I'm happy to send it to you ...)
Off hand, the only thing I'd change locally is to change the
conditional block into a guard, and get rid of `$size`.
while(<LOG>) {
my @entry = m/$c_parse_apache/o;
next if not @entry;
$g_hits++;
$g_transfer += $entry[LOG_BYTES] unless $entry[LOG_BYTES] eq "-";
$g_hits[$entry[LOG_STATUS] / 100]++;
&sort_entry(@entry);
}
I might change more things if I saw the entire script; I'm not
sure. Depends mainly on what `$c_parse_apache` contains and where
else it's used, I think; also, what `sort_entry` does. If you're
genuinely interested in learning, and the script isn't big, sure,
send it along; I can't be bothered to work on it if it's just to
prove a point, though.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
