re: <i>open() creating temporary file if file arg is undef</i><p>Fortunately both IO::File (core module) & Path::Class don't do this:<p><pre><code> use IO::File;
my $fh = IO::File->new( $config->{file_path}, 'r' )
or die "can't open $config->{file_path}: $!";
use Path::Class qw<file>;
my $fh = file( $config->{file_path} )->openr;
</code></pre>
Both above spot the undef gotcha. NB. And <i>->openr()</i> throws an exception.<p>ref: <a href="https://metacpan.org/module/IO::File" rel="nofollow">https://metacpan.org/module/IO::File</a> | <a href="https://metacpan.org/module/Path::Class" rel="nofollow">https://metacpan.org/module/Path::Class</a>
Maybe they should use classes and objects instead of hashes. I.e.<p><pre><code> $session->ab_variation_overrides();
</code></pre>
This would prevent them from mistyping ab_variation_overrides everywhere they need it... But of course, it's a lot easier to solve everything with hashes in Perl. Been there, done that!
I basically gave up on perl after discovering this:<p><pre><code> foo foreach @bar;
sub foo {
s/foo/bar/
print;
}
</code></pre>
This clobbers the content of @bar due to mutating the $_ variable.
Which is a useful feature. But imagine that foo, instead of directly mutating the value passed to it, calls into a complex set of other code. Now you have a bomb where working code can break in crazy ways if any of it gets changed to modify $_.<p>Having to audit code for this kind of thing is a real pain. I still maintain existing perl projects, but won't be starting any new ones.
Both OPs examples would be spotted by unit tests and finding actual bug after that is quite trivial.<p>So I agree, you can trigger some features unpredictably, but this just shows power behind tool and remind you to be well self-organized =)
I love Perl. I wrote it professionally for 10 years. I have great friends who still do. The community is full of smart, fantastic people.<p>Five years ago, however, I learned Python for a job and never looked back. In terms of programming languages they're practically the same thing. But Python is easier to read, easier to write, and easier to hire for. And stuff like this (dereferencing, "array context," worrying about how to create my objects) makes me sigh.<p>Perl, I love you, but I'm not looking back.<p>(apologies for the language flame war bait)