The purpose of testing “attributes” is not to test that Moose did its thing. The purpose of testing attributes’ accessors is that they are part of your class’ interface. That an accessor is backed by a Moose attribute is an implementation detail. Just because get_foo() is an attribute accessor today doesn’t mean that the data won’t be stored elsewhere in the future or even be derived from something else.

What you shouldn’t be doing is using has_attribute_ok() from Test::Moose, again because where the data returned by the accessor is coming from shouldn’t matter to users of your class.

Even if PPI supports it, Perl::Critic will not be supporting any syntax that’s not part of the language core. Not only because it would be necessary to figure out semantics, but because I oppose balkanization of the language.

To quote myself: “Please add a ‘class. keyword. Would that break MooseX::Declare? Yup. Tough cookies.“

Don’t suffer brokenness. Fix it.

On the Perl::Critic project, we ran into problems with this. We got failures when people had the environment variable set for their own purposes. The code that checked for enabling author tests also turned them on if there was a .svn directory around, so, of course, we got a complaint when someone grabbed the source from the Perl::Critic repository. *sigh*

The proper way to enable author tests is to require the user to explicitly say that she wants them to be run.

The first thing to do is to segregate the non-standard tests from the regular ones so that the standard testing tools don’t run them by default. At the 2008 QA hackathon in Oslo it was decided that these tests belong under the “xt” directory in a distribution; there was no mandate about substructure. I’ve been using “xt/author” for my author tests.

The second step is to create a “authortest” build target. Since I use Module::Build as my build tool, this example will use that. The way to create a custom target in Module::Build is to create a method on a Module::Build subclass with a name that starts with “ACTION_”. Here’s my standard “authortest” code:

First this asks Module::Build to ensure that the build, manifest, and distmeta actions have been run because some of the tests depend upon the MANIFEST and META.yml files being around and I don’t check those into source control. Line 8 tells Module::Build to look in the standard “t” directory plus “xt/author” for tests. Line 9 says that the test files may not be directly in these subdirectories. Finally, it asks for the regular test action to be run.

Using this, running the standard “./Build test” command doesn’t run author tests, no matter what the user’s environment is. And simply running “./Build authortest” causes all the tests to run. Simple, yet explicit.

To ensure that nothing gets released without the author tests being run, I change the distdir action to require the author tests be run:

• Your code is more testable. You can feed in arbitrary command lines and check the exit code.
• Your code is reusable. If you need to use your program from another Perl program, there’s no need to use system, backticks, or IPC::System::Simple, just use your module and call the implementing subroutine.
• Your programs can be better managed by the standard Perl toolchain. Program versions are not checked by CPAN, et. al. so if you create a new version of an existing program, it won’t be upgraded. If all of your code is in a module, then version changes will cause updates to be installed.

A simple way of doing this would be to have a module that looks like

and then use that like this:

Having the “return 1 if caller” in there means that the program can be required without causing the requiring program to exit. (Whether you ought to actually do that is another matter.)

If you want things to be even more reusable, make your program implementation an object with attributes for the standard file handles:

Your regular program would then look like this:

But you can have other uses like

This release is dedicated to Tom Wyant in appreciation of the amount of effort he put into the enhancements and bug fixes in this release, for having the patience to wait for the amount of time that it took to get them out, and for overall awesomeness. Thank you, Tom.

There have been a lot of discussion recently in the Perl community about what deprecation means. For me, deprecation means that the interface or functionality will be removed and not sit around in a limbo state for years.

So how do I decide whether to deprecate something? If something is merely suboptimal, I’m not going to deprecate it; I’ll merely change the documentation to discourage its use. In Perl::Critic, there was the issue of Policy constructors. For a long time, there was no requirements for the new() method for a given Policy other than it returning a blessed hash. There are some Policys [sic] outside of the core distribution with new() methods that don’t call up to the new() method in Perl::Critic::Policy. There was a point when we really wanted to add a lot of functionality to the constructor, but we couldn’t because there were Policys that didn’t call it. We worked around this by doing what we wanted after the Policy object was constructed. If you look at the developer documentation for Perl::Critic, you’ll note that it discourages creation of a new() method.

On the other hand, if something is incorrectly designed or is holding up future changes, I’m going to change it or remove it. I’m not going to just work around the issue forever. I won’t change it without notifying anyone, however.

I made a mistake with the design of Perl::Critic::Utils::PPI::get_constant_name_element_from_declaring_statement(). I didn’t realize that you can actually create multiple values using the constant pragma; Tom Wyant corrected my misconception. The function returns a single value, so it can’t correctly handle single statements that declare multiple constants. Its interface is wrong. It will be removed in the future. A suggestion was made to immediately remove it, but we’ll go through a deprecation cycle first. We won’t change things without giving notice.

I think the Policy author’s question about the warnings comes from the practice of a number of projects of “deprecating” something, but never actually removing it. Sun is a particularly egregious example of this with Java functionality that has been deprecated for more than a decade but still hangs around, allowing people to write new code against an interface that is broken. If I deprecate something, it will be removed. The warnings that are emitted allow others to deal with the change before it happens. If, in the interim, this annoys some users, too bad. It would be worse if the code just stopped working.

If you have a look at my code page, among the epigrams that you find there is “If it’s broken, fix it.”. While there has long been the saying of not fixing something that isn’t broken, I think people don’t do the opposite enough. Don’t suffer breakage. Don’t put up with things that are wrong. Change things that need changing, even if it causes some short-term pain.

For code that I release to the CPAN, the Perl::Critic tests are in xt/author so that they don’t get run as part of normal tests that someone installing the modules runs. On someone else’s system, I don’t know what Perl::Critic version or add-on sets of policies they have, so those tests may fail there through no fault of my own.

For non-public code, the Perl::Critic tests are regular tests that get run with all the rest of the tests. I can do this because I control the specific version of Perl::Critic that I’m running and which add-on policies that I’ve got around.

Perl::Critic supports the concept of severity levels for policies and, by default, only applies the most severe ones (severity 5). I effectively ignore the severities by turning Perl::Critic’s strictness all the way to 1. Of course, there are policies that I don’t agree with or cannot use for practical reasons, so I disable those explicitly.

You may have noticed that above I used the word “tests” and not “test”. This is because I run Perl::Critic on my tests as well as my “real” code. The set of policies that I use on tests is different than I use on the rest of my code. Tests have fewer restrictions on them compared to regular code. So I have a test that applies to the contents of lib and bin using one perlcriticrc file and a seperate test that runs on the content of the t and xt directories with a different perlcriticrc. For tests, I disable the POD policies and Subroutines::ProtectPrivateSubs (tests are allowed to peek). Sometimes I also disable ValuesAndExpressions::ProhibitMagicNumbers, though I prefer not to.

(Perl::Critic actually uses three self-compliance tests: one for the regular code, one for the tests, and one that makes an additional pass over the Perl::Critic::Policy subclasses that places some additional requirements on them.)

The sets of add-on policies that I generally use are Perl::Critic::More, Perl::Critic::Bangs, Perl::Critic::Swift, and Perl::Critic::Moose. I’m thinking about starting to use Perl::Critic::Pulp, but I’d have to disable about half the policies in there.

There are a couple of cases in which I do use perlcritic.

First, if I’m surveying a codebase that is new to me, I will run perlcritic --statistics-only over it in order to get an idea of the state of affairs.

Second, presented with a set of code that has a large number of problems that need fixing, after running perlcritic --statistics-only on it, I’ll pick an individual policy that I want to fix violations of and run perlcritic -s policy name on the code. (The long form of -s is --single-policy.) I find it easier to fix one kind of problem across all of the files before moving on to another kind of problem than to fix all the problems in one file before moving on to another file.

But why?

If you’re going to go to the trouble of compiling a new perl executable, how much more effort is it to recompile everything else in your install? If you’re using continuous integration, don’t merely use it on your code, use it on the CPAN modules you use as well.

The whole idea of mixing point releases seems like it’s a nightmare waiting to happen.

Actually, why are you upgrading an existing perl installation at all? What if there’s some code that can’t deal even with a point release upgrade? You shouldn’t force that upgrade on others in your organization. Put the point release into a different directory and lock it down. Don’t use site_perl; install all of your modules into some private area and use PERL5LIB. (Learn to use INSTALL_BASE with ExtUtils::MakeMaker and install_base with Module::Build.)

Pod::Coverage::PPI

Like Pod::Coverage, but rather than looking at the symbol table, uses PPI to discover subs that need documenting.

Pod::Coverage::Moose

Like Pod::Coverage, but, in addition to regular subroutines requiring documentation, reports on Moose generated accessors, delegations, etc. that are undocumented.

Pod::Coverage::PPIMoose

Combines the two others.

Let me say emphatically that one of the core Perl::Critic developers (i.e. me) loves autodie. If he could, he would marry it.

If you aren’t using autodie, please do so.

Please use autodie. PLEASE use autodie. PLEASE “use autodie;”!!!

(Or, even better “use autodie qw< :all >;”.)

The proposed answer is for Modern::Perl to take a date parameter to indicate what “modern” means. This is brilliant because it explains to even the unknowledgeable programmer when the code was current. Say the syntax is like:

    use Modern::Perl as_of => '2009-06-23';

What could be more clear?

• There are some amazingly smart people working on Parrot/Rakudo who really believe in the promise of both.
• I need to actually start learning Perl 6. My wrote my first baby Perl 6 programs Saturday. It’s nice to have something that’s like (for some definition of “like”) Perl 5, but organized from the start so that things are consistent. Right now, all I see are the problems from Perl 5 that have been fixed; I don’t see any of the problems that exist in Perl 6 yet.

• A lot of the introspection functionality isn’t there yet. Since things are still in flux, there isn’t a lot of concrete documentation on what each class does. Thus, I figured the easiest way to learn what’s there, as opposed to what’s in the spec, was to first figure out the introspection mechanisms and use those to poke around. It turns out that the $foo.HOW().^attributes() method doesn’t exist yet, so looking for the structure of classes isn’t possible yet. However, the $foo.HOW().^methods() method does exist, so I started exploring that. My first try at simply listing the methods on an object (say $_ for 1.^methods()) resulted in some expected stuff, but there were a bunch of “1″s and “2″s in there. It turns out that those are collections of multi methods (which are like overloaded methods in other languages, but the determination of which variant to use is made at runtime, not compile time). This is when I learned that a bunch of Rakudo classes (e.g. the multi method classes) are actually Parrot classes (currently) and thus they don’t act like Perl 6 classes are supposed to, so it’s hard to introspect those.
• With the goal of starting on Perl6::Critic, I learned that I can get a parse tree via my $parse_tree = Perl6::Grammar.parse($source_code); or my $parse_tree = Perl6::Compiler.compile($parse_tree, :target('parse'));, or even get the abstract syntax tree via my $ast = Perl6::Compiler.compile($parse_tree, :target('past'));.
• I had heard that Perl 6 supported classes and prototypes, but I had no idea where the prototypes came in. It turns out that Perl 6 classes are actually implemented as prototypes. In fact, classes are “instances” of themselves, specifically the undef instance. So, when you declare a typed variable, but don’t provide an initial value, the undef that the variable gets initialized to is the class itself. Given

      my SomeClass $x;
      my $y = SomeClass;
  

  $x and $y refer to the identical thing. This is seriously cool stuff.

• Parrot is far enough along that people are actually discussing cross-language issues such as IPC and standard Parrot libraries.
• Some people aren’t happy writing code in “assembly language” (PIR) and are thus creating “C” for Parrot (Close, as in “close to C”).
• Rakudo cannot handle the official Perl 6 grammar, STD.pm, yet, so I need to work with the Rakudo grammar.
• I can actually see an approach to tackling Perl::Critic for Perl 6. The first thing I want to do is create a ppidump for Perl 6. Parrot has a means of doing this, but I want something in regular Perl 6, not only for the functionality, but to learn how to walk the parse tree. The next step is to implement a ProhibitMagicNumbers program; no configuration, no options, just take a set of file names and spit some stuff out. Patrick suggested that I could subclass the grammar and use actions on it to find the numbers and look at the surroundings; that would work for a specific policy, but this initial program would be an exploration in how to do the real Perl::Critic and I don’t plan on a grammar subclass per policy. (That would mean that each file would need to be parsed individually for each policy.)

I’ve been using the constraint syntax for describing complicated data structures in POD and comments in cases where Moose isn’t actually involved. It’s nice to be able to simply state that a subroutine returns “ArrayRef[HashRef[Maybe[Str|HashRef[Foo::Bar]]]”. That’s a lot more comprehensible than a paragraph of description.

I am not presently involved with Parrot, nor do I expect to be in the future; I’m already behind on the projects that I’m involved with or want/need to start. At most, I expect that I’ll be filing bug reports.

I’m expecting that I’ll be using things running on Parrot. I want to understand what’s going on underneath in order to make my life in understanding higher level things easier. As a point of comparison, there are some edge cases in Java’s behavior that you cannot understand without knowing how the Java virtual machine works.

I want to know how to drop to a lower level, if the higher level code running on the VM isn’t working out for some reason.

When dealing with Perl 6 specifically, I want to know what I can get at the Parrot bytecode level and what I need to do with STD.pm. I’m probably going to be involved in a Perl 6 version of Perl Critic and I’d like to know what would be possible in terms of a generic higher-level-language-running-on-Parrot critic. (Yes, I don’t know how to use a programming language that’s still not finished being designed and I’m already planning on to tell you that you’re using it wrong.)

Instead, I’m going to give an example of how NYTProf told me why I shouldn’t fix something a particular way.

I’ve got an app that needs to analyze a bunch of logs. Having used NYTProf in the past to identify that creation of DateTime objects is my biggest issue, I was thinking of ways to improve the situation. One thing I thought of is being able to create a DateTime based upon an epoch time instead of individual date components (year, month, etc.), with the idea that the cost of deriving the epoch time from the date components was what was expensive (I can affect the format of some of the logs, and thus could get the epoch time emitted). So, I quickly threw together a little Benchmark program that compared the costs of constructing DateTimes from each type of data. I was shocked to discover that creating objects based upon epoch times was over 20% more expensive than creating them out of date components.

What was going on? NYTProf provided me with the answer. I created two simple programs that created 100,000 DateTime objects, one for each kind of constructor arguments. I profiled both of them and compared the NYTProf output for them. This led me to looking at the from_epoch() code in the NYTProf generated HTML, and finding that DateTime passes the epoch time to gmtime to get the date components and then calls the regular constructor with those. The extra cost isn’t really in the gmtime calls, but a good part of it is in the use of Params::Validate in all of the public methods to check arguments and the epoch time path takes the code path through an additional public method.

Benchmark told me that I shouldn’t make a change and NYTProf allowed me to understand why that that result was correct and there wasn’t something wrong with my Benchmark use.

Why? Continuous integration.

Don’t just grab modules from the CPAN and install them somewhere never to be upgraded until you’re forced to at a huge amount of time and expense. Regularly rebuild everything you use, preferably daily or hourly.

1. Install a perl binary and then lock it down. Don’t use site dirs. Have the perl core be inviolate.
2. Instead, install to some other directory and point PERL5LIB at it. Both CPAN and CPANPLUS allow you to configure what you want to be passed to the configuration program. Pass a value for INSTALL_BASE to Makefile.PL and install_base to Build.PL that points to your directory.
3. Set up a build server to use CPAN or CPANPLUS to “install” and build everything. Since your build machine will be rebuilding everything regularly, when you upgrade your perl binary or an XS module, any problems will be quickly identified. Everything being rebuilt in one go means that all binary code will match up and you don’t have to worry about them getting out of sync. Because installing a distribution causes all of that distribution’s tests to be run, you’ll know that that distribution works in your environment.

(If you’re using taint mode and thus cannot use PERL5LIB, have your build machine build a custom perl executable along with everything else.)

Details for doing this belong in another post. But the point is, if you regularly rebuild all of the CPAN code you use, you don’t need to worry about binary issues.

The former has been in progress for a while as part of brian’s BackPAN indexing work. The latter is a more recent effort at creating a tool for managing CPAN-like repositories. It can copy archives into a repository and update the standard index files. It’s being used on a daily basis on both Windows and Linux to maintain a single DarkPAN at present, and, once some more work on automated building of Perl distributions under TeamCity is done, will be used for maintaining a lot more private repositories.

The way that a repository is updated is to have a copy of it checked out of Subversion, put the distribution archive in place, run dpan on it to update the indexes, and check in the result. CPAN.pm can be pointed at the Subversion HTTP URL and use it just as if it were one of the public CPAN mirrors. (Though of course, the DarkPAN repository has a restricted set of distributions in it, not even a mini-CPAN.)

However, as a practical matter, Modern::Perl is broken. What happens when perl 5.12 comes out? Does chromatic upgrade the module to add “use feature qw/ :5.12 /;“? Are all of the modules that use Modern::Perl suddenly broken? Someone requested that TestingAndDebugging::RequireUseStrict include Modern::Perl in the default set of modules that are treated as equivalent to “use strict;“. (You can add to that list yourself via the “equivalent_modules” option.) I don’t want to do that; I want to discourage the use of Modern::Perl. Maybe if there was a Modern::Perl_5_10 I’d think differently.

The ones that I use on a daily basis are pmpath, pmvers, and pminst.

I use pminst and pmvers to maintain a couple of DarkPANs, a.k.a. internal CPANs. I want to manage the versions of modules we use so that we don’t get surprises, like they won’t compile in our environment or they make changes that we can’t deal with right away. So, we have repositories in the standard CPAN layout and point CPAN(PLUS)? to those instead of the public CPAN.

Since the install tools are pointed at an internal repository, when I want to use a module that we haven’t used before, I need to download the distribution myself. It’s not as simple as just grabbing the distribution archive. I need to get the module’s dependencencies. In order to find out which of those I’ve already gets installed, I use pminst.

If I run into a problem with a module, I need to figure out which version I’ve got in order to look at whether there’s an updated version or to properly report a bug. Thus, pmvers.

I regularly need to figure out what path I’m getting a module from, for example whether it’s in the core perl install or in my installed modules path. (In order to avoid cross-project module version entanglements, we don’t use sitelibs; we use separate install directories. The core perl installation is readonly and nothing ever gets added to it.) pmpath probably gets the most usage of the three.

The most common of my use of pmpath isn’t actually direct. When I get an exception in some module, I want to bring it up in the editor to see the code. I’ve created a script that I call pmedit:

I’m quite chuffed.

I’ve got a base message class with a subclass for each exchange. For the former kind of differences, I’ve got an abstract method on the base class with the appropriate implementations on the subclasses. For the “WTF?” things, I’ve got a default implementation on the base class, and override that on the specific subclass.

Adam Kennedy wrote a journal entry where he mentioned “the expense of having to maintain [## no critic] entries permanently”. This inspired the creation of the new policy.

One of the problems with Perl::Critic is that you may, over time, end up with policy disabling comments scattered across your code that no longer apply, making the code harder to understand. This policy will complain about any ## no critic that doesn’t actually disable any policies. You then know that you can remove those comments, making your code cleaner and congratulating yourself for solving whatever issue that caused you to put it there in the first place.

This post originally appeared at use.perl.org.

Every time this comes up someone says “but what if they collide?! Hashes sometimes collide!”

I confess to being one of those who want things to be really impossible, not merely “statistically impossible”.

Dang, writing good answers takes time.

There’s a great new page on the Perl 5 wiki about administering your perl installation. It includes quite a number of things I believe in. Some of the more significant bits:

First and foremost thing I can say is if you depend heavily on Perl (or any single piece of technology) build it yourself. This will allow you finer control and faster upgrades than your OS vendor can. Windows is the exception, Strawberry Perl does a much better job packaging Perl and tweaking it for Windows than you can (and if you think you can better, please contribute to Strawberry).

This is especially true on Red Hat. Ignoring general management issues, you really ought to have a threaded and a non-threaded perl so that single-threaded code doesn’t pay the overhead for threads.

Fourth, keep up to date. This means keeping CPAN modules and perl itself at or near the latest versions. This will incur the occasional breakage as you encounter either intermittent bugs in new versions of CPAN modules, or API changes, or project code that accidentally depends on certain versions of CPAN modules. But it’s worth it, because the farther you fall behind the harder it becomes to catch up. As your perl gets older and older, fewer and fewer CPAN modules will work requiring more and more patching to get them working. As your CPAN modules get older, it will require a greater leap to bring them up to date, and more upgrades simultaneously. The sudden upgrade will cause many bugs to happen simultaneously making them take far more time and effort to track down then if they could be dealt with individually. Large upgrades require large effort, time and risks. Small upgrades require small effort, time and risks. The looming risk of a large upgrade will make developers settle for an older, buggier, less capable version and write a work around rather than risk the upgrade. This creates a hidden drag on your project and creates more and more complex code to maintain.

Another point: when you discover a bug in a CPAN module, there may be a fix for it, but if you’re very out of date with it, it may cause significant problems with other modules, making your upgrade of that one module really painful.

At Barclay’s, it took me 7 months to upgrade them from perl 5.6 to 5.8 and the latest version of other modules. Way too long.

If you’ve got good test coverage, you should be able to easily find any problems with upgrades.

I just got though producing a set of constants for FIX message types and fields. I hate abbreviations that come from outside the problem domain, i.e. that an end user wouldn’t understand. I hate abbreviations in general, but specifically for “number” because there’s three different common ones in use. FIX uses two of them, with no clear reason for the difference.

In the world of finance, “FX” is a reasonable abbreviation to use in names, because the end users understand what it means. In FIX, there’s a field called “DKReason”; care to guess what “DK” stands for? If you said you “don’t know”, you’re correct. Yes, it literally stands for “don’t know”. The description for the field is “Reason for execution rejection.”, but if you’re reading through unfamiliar code and see “DKReason”, how the hell are you expected to understand the significance without hours of digging?

CPAN::Site does most of what I want with maintaining it. Unfortunately, it has some bugs with parsing module versions (in particular Test::Object, which is a blocker for PPI); in particular, it can’t distinguish between namespace declarations in actual code and in code examples in documentation. I thought that it could be worked around, but in reading source, it’s doing some pretty incredible stuff.

It’s reading perl code straight out of raw tar files. It ungzips the tarballs, but doesn’t untar them. It simply tries to find perl code in the middle of the tar stream and grab the versions out that. Yech.

So, looks like I’m going to be forced to go back to CPAN::Mini::Inject, taking advantage of parse_version() in ExtUtils::MakeMaker. I’m going to have to have a look at brian d foy’s MyCPAN::Indexer work.

What sorts of things are these for?

Have you had a look at Perl::Critic 1.082? Have you read Perl::Critic::DEVELOPER? What do you think?

This post originally appeared at use.perl.org.

Generally, Perl::Critic is being used indirectly via a test using Test::P::C or Test::P::C::Progressive, with a perlcriticrc file that is in the distribution’s t/ directory.

The most common reason I have for running perlcritic is when there’s a Test::P::C::Progressive failure. In that case, I’m looking for violations of an individual policy to fix to get the violation count down.

--single-policy overrides all other selection criteria for policies. Its value, like the ones for the --include and --exclude options, is used as a regex applied against policy names with the /i, /m, and /x options applied to it. So, for example, if I want to scan for violations of Modules::RequireNoMatchVarsWithUseEnglish in the current directory, I can simply say

perlcritic --single-policy english .

When cleaning up a body of code, I find it easier to fix one kind of problem at a time in a bunch of files, rather than fixing all kinds of problems a single file at a time.

This post originally appeared at use.perl.org.

One, this allows initialization to be deferred to the point where we know that the policy is going to be used. P::C::PolicyFactory always instantiates every Policy that it can find. It is up to the P::C::Config object to filter that set down. Primarily, this is an issue for Policies which dynamically load other modules.

Two, this method enables the Policy to decide for itself whether it should be enabled. This means that a Policy that depends upon a module that might not be present can remove itself from the set that violates() gets called on, thus speeding things up because it isn’t being called on every PPI::Element.

This originated from Chris Dolan’s work on the Perl Foundation grant to create the remaining Policies that can be implemented that enforce one of the ideas in PBP. Specifically, for Documentation::PodSpelling, but this change has been made to all the configurable core Policies. In particular, this helps CodeLayout::RequireTidyCode.

Differences from a constructor other than the obvious first parameter:

1. The configuration is passed in as a hashref and not a hash an instance of Perl::Critic::PolicyConfig (corrected 2009/5/16).
2. initialize_if_enabled() returns a boolean specifying whether the Policy should be enabled.

This is how the two above policies bow out.

This post originally appeared at use.perl.org.

As of the recent 1.07 release, Perl::Critic, has started using Readonly to be more more self-compliant with Perl Best Practices. We had been avoiding use of constant for the reasons described in the book, but had not been willing to add the Readonly dependency until now.

The Perl::Critic coding standard has been to use sigils for subroutines in @EXPORT_OK, etc. and import lists, but Exporter treats them as optional. And, in fact, there’s code that strips them off (line 47 in v5.58). I haven’t figured out the commonality, but in a few environments, this fails spectacularly. Once we removed the subroutine sigils from everywhere, the problems have gone.

Explicitness: 0, Keyboard laziness: 1.

This post originally appeared at use.perl.org.