
Ugly Old Perl - fogus
http://blog.laufeyjarson.com/2010/11/ugly-old-perl/
======
pilif
This pretty much applies to many other languages too. As new constructs get
added but old ones are not deprecated or even removed.

Then again, removing language constructs is a sure-fire way not to get any
adoption of the new version (cf. Python 3).

In my case, it's not old Perl idioms that stick around, it's old PHP idioms.
Like Perl, PHP too has moved forward, especially with 5.3. But because the old
code continues to work ad-infinitum (how many years did it take for PHP 4 to
die? Right. It's _still_ alive, even though most PHP4 code runs unaltered in
PHP5), nobody is taking advantage of the new features.

While I can understand this in public projects (you want to be as broadly
compatible as possible), for private projects, I certainly would want to use
the latest and greatest as it helps both keeping the code clean and future-
proof it.

Here in the office, we've introduced the concept of a raptor incident
(<http://xkcd.com/292/>). We use this to denote old idioms being used and
general lazyness-related code smells.

We are counting the raptor free days and whoever causes a raptor incident will
get the the accumulated stack of post-its with incrementing numbers counting
the raptor-free days.

It already helped tremendously at keeping people concerned about their output.

------
zaphar
I'm one of those people who achieved enlightenment with haskell and Lisp and
yet still enjoys firing up perl for the occasional project or script.

Perl is still very much alive and not at all stuck in a bad place. It may be
easy to get that impression in your local circumstance but in the larger sense
Perl is thriving. It's even _gasp_ still grabbing young developers. I wouldn't
worry too much about it.

~~~
sigzero
Not only that but Perl 5 releases are now picking up and very good things are
being backported from the Perl6 effort. There is a lot of talk on cleaning up
internals and doing things that make P5 better over all. I am very excited
over it all.

------
drv
At first glance, I didn't see anything wrong with the code shown (aside from
using << instead of >> for append). I must be one of those ugly old Perl
hackers; I probably have an old edition of the camel book somewhere.

Constructively, though, what is wrong with the code snippet? The improvements
he lists don't improve this case at all. Three-argument open vs two here is
debatable (I doubt $runpath is insecure input), but fancy filehandle-in-a-
variable doesn't gain anything when it's just in use over three lines.

~~~
lysium
Don't know why you're downvoted. I also missed his point why his alternative
solution is in any way "better".

~~~
phaylon
Code like this:

    
    
        open my $fh, ">$file" or die "...";
    

will append to target if $file contains ">target". Code like this:

    
    
        open my $fh, '>', $file or die "...";
    

explicitly tells Perl what the mode and what the filename is, so there can't
be any confusion.

Using lexicals instead of typeglobs means you store the filehandle in a
lexical variable instead of making it globally accessible in your package.

~~~
Xurinos
And ultimately, wouldn't this be even more "modern", even clearer? --

    
    
        my $file_path = Path::Class::dir("some_path")->file("file_name");
        my $fh = $file_path->openw();
        $fh->print("my line\n");
        $fh->close();
    
    

Or for reading the whole file quickly, instead of the @var = <FILE> idiom --

    
    
        my @var = $file_path->slurp();

~~~
phaylon
It can be, of course. There is more than one way to do it, because there's
more than one situation in which one wants to use it. Most of my larger
projects use Path::Class, but none of my scripts in ~phaylon/bin do, since I
want to use some of them even if I don't have a perl setup yet.

Another reason might be that you're writing a CPAN module and don't do much
with files. If you just use it to write a debug log when an environment
variable is set, you might not want to include another dependency.

What your code demonstrates very good in my opinion is the fact that lexical
filehandles are just more interoperable. You can pass them around
transparently like any other reference, use modules that pass them around, and
so on.

------
olaf
I'm too lazy to read through the changelogs to filter out the latest features,
idioms. Is there a place on the web where interested developers can update
their knowledge, sth. like an overview over the state of the art of Perl (most
important improvements since 5.8, e.g. smart matching etc.)?

~~~
billswift
You might try here, <http://planet.perl.org/> , though you'll have to wade
through a lot of other perl stuff. They aggregate several perl blogs.

And there's a lot of good stuff here,
<http://www.modernperlbooks.com/mt/index.html>.

~~~
draegtun
For even more comprehensive Perl blog aggregators try:

* Planet Perl Iron Man (<http://ironman.enlightenedperl.org/>)

* Perlsphere (<http://perlsphere.net/>)

