Ugly Old Perl | Hacker News Reader

Ugly Old Perl

blog.laufeyjarson.com

37 pointsfogus17 comments

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.

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.

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.

One of the many things I love about Perl is how you never get that feeling of "I'm writing this again?" It's the first language I've used that really helped the developer, and it's what still brings me back to using the language.

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.

The real danger is in the habit, not this specific code snippet. Two-parameter open includes the ability to open to and from arbitrary shell commands. I can and have used this to escalate to root out of "nobody" with the combination of a bad two-parameter open and an excessively permissive sudoers file. It's better to just say never use two-parameter open; there's no reason to do it.

$runpath might be safe now, but it doesn't have to be forever. It could come from a config file one day.

I'm not sure why using a lexical variable to store a filehandle you only need lexically is more fancy than storing it in a globally accessable package typeglob for anyone to use and modify. But it does give you the advantage that your garbage collector will close your file handles instead of you having to do it manually. If I see close($fh) in my own code, I know I had a reason other than "I didn't need it anymore."

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

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.

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();

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.

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.)?

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.

For even more comprehensive Perl blog aggregators try:

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

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

http://perl101.org/

http://modernperlbooks.com/mt/index.html

http://www.effectiveperlprogramming.com/

From the command line:

> perldoc -f open

Modern Perl website has a free pdf of the book. Thank you!

Better/easier (to read) than the changelogs are the Perl delta docs: http://perldoc.perl.org/index-history.html

Update. See the major version deltas for a complete summary of new features:

* 5.12 - http://perldoc.perl.org/perl5120delta.html

* 5.10 - http://perldoc.perl.org/perl5110delta.html

Reply on news.ycombinator.com