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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Full support (Score:2, Insightful)
For the record you have my full support on the use of map in void context. I use if quite often and even find a certain pleasure knowing that it would not pass a certain guru [perlmonks.org]'s code reviews ;--).
mirod
Re:Full support (Score:2, Informative)
Re:Full support (Score:2)
Re:Full support (Score:1)
Re:Full support (Score:2, Interesting)
I didn't think much about it because I didn't know the optimization was supposed to have been done. Plus we all found shorter solutions later on that didn't have the memory problem.
Re:Full support (Score:2)
I second that as well, in fact map in void context should be compulsory in Perl code to decide whether it's any good ;)
The only time I've been bitten by it is on one of those occasions when I threw a map in naturally, only to notice later that a for loop would have been much simpler. But that's trivial to fix...
-- Robin Berjon [berjon.com]
Functional Perl (Score:2)
Functional programming goodies (Score:1)
For the record, I agree with you 100%. Something's just fun about map, grep, Schwartzian transform, and things like that.
Have you seen Ben Tilly's writeup Why I like functional programming [perlmonks.org] in the monastery? Great stuff.
map() in void context (Score:1)
Why is using map() and ignoring the side effects any better than using grep() for the same purpose? Just because grep() is one character longer? It seems obfuscatory, but I must be missing something.
I might write the line as
which seems to communicate the idea more clearly.
Maintainability (Score:1)
Paradigm shifts often take time.
Re:Maintainability (Score:1)
Here! Here!
The problem with functional code is that most fresh meat, er, new hires/newbies won't grok what's going on in the code. By using procedural idioms over the functional ones, your code is more likely to be understood by others (and maybe even you) in the future. Using language neutral idioms in public Perl code goes a very long way to squashing Perl's "unmaintainable, spaghetti code" reputation.
Does that mean eschewing
mapandgrepall together? I don't think so. It is better to limit the use ofRe:Maintainability (Score:2)
Nice and succinct, and I think easy to understand (though I should probably be using File::Spec for portability, but *shrug*). I also partly wish you could do filters like this, sort of like SAX pipelines, so I could do something like:
I'm sure pdcawley will now pipe in how Perl 6 will be able
Re: Fav. map/grep idioms (Was: Maintainability) (Score:1)
@stuff = sort keys %{{ map {$_ => undef} @stuff }};
gets a sorted list of uniq entries in @stuff.
I always use undef instead of 1 for insignificant hash values because it just *seems* like it should be more efficient. I've never benchmarked any stress-tests though.
-matt
Re:Maintainability (Score:3, Insightful)
Any style can be abused to produce good or bad Perl code. Erring on the side of "procedural Perl" for the benefit of newbies doesn't mean it will naturally be easier to understand. I've seen grotty Perl code that's using a classic FORTRAN style, so I'd say that it's more important to write clearly than to write in a specific style. I've also seen code that's bee