use List::Util qw( shuffle );
my @files = glob( '*' );
@files = grep { -f } @files;
@files = shuffle @files;

Of course you can combine that into one expression:

use List::Util qw( shuffle );
my @files = shuffle grep { -f } glob( '*' );

Or from the command line:

perl -MList::Util=shuffle -le'print for shuffle grep {-f} glob("*")'

Don't worry that List::Util is a module, because it's a core module that's been included with Perl since 5.7.3

$ corelist List::Util

List::Util was first released with perl 5.007003

The shuffle function is extremely simple, and how here's a little article that explains why it works.

Consider your privacy. Consider whether a company whose sole business purpose is to sell targeted advertising by extracting, sharing, and mining personal information from millions of people. (Do I mean Google or Facebook?) A fan of free markets and free information might say "Whether any individual finds that objectionable, an informed citizen should have the right to decide whether to participate."

The assumption is that citizens should be able to know what information the business shares, with whom, and why. It's easy to understand why. Even though it's funny to laugh at a petty criminal caught by posting a stupid update which gives the authorities reasonable suspicion of a crime, it's unsettling to imagine an abused and estranged spouse who's dutifully followed the guidelines for not allowing personal information to escape a hand-vetted circle of trustworthy family and friends fall victim to an unannounced, opt-out rule change which allows the abuser to perpetuate the abuse.

The parallel to Perl is subtle, but important. If you want to improve your software, sometimes you have to make incompatible changes (or learn how to predict the future, or write software so trivial that you always get it right the first time), but changing the world out from under users is irresponsible and unethical.

The difference between managing your privacy and safety in a world where mass communication is cheap and easy and between having to change the use of a long deprecated feature is vast, but in both cases there's a simple ethical concern: retroactive and arbitrary and unannounced and forced changes are wrong.

That's why My Contrarian Stance on Facebook and Privacy is very, very wrong:

[Let's] not make privacy a third rail issue, pillorying any company that makes a mistake on the privacy front. If we do that, we'll never get the innovation we need to solve the thorny nest of issues around privacy and data ownership that are intrinsic to the network era.

Don't let the shiny of the Internet hero de jure fool you. The technical world needs less "innovation". (I'll take less of the kind of "innovation" which suggests that if I didn't want to share information publicly last month, I suddenly want to this month without you even asking.) The technical world needs more grownups who don't get distracted by multibillion market caps, the inherent sexiness of enterprise software, and whatever His Jobs announces next week. The technical world needs people who treat other people ethically. If that means pillorying entities which act unethically, then so be it.

• CPAN Meta Spec version 2 — I released the final spec and will soon be looking to rally toolchain developers to implement it.
• CPAN Testers 2.0 — I launched CPAN Testers 2.0 Beta site, the eventual replacement for the current practice of sending CPAN Testers reports over email and I’m continuing to monitor it, tweak it and fix little bugs
• Perl 5 core development — I’m scheduled to be the release-engineer for Perl 5.13.3 in July. In addition, my goals for Perl 5.13 include getting HTTP support for CPAN clients into the core, simplifying CPAN configuration further and implementing CPAN Meta.
• Drafting a formal description of the expectations for Perl build systems that use Build.PL. Right now it’s only Module::Build, but it could be other things in the future. I’ve started a very rough draft of what cpan clients should expect Build.PL (and the resulting Build) to support.
• Dist::Zilla — I’ve been converting my distributions over to Dist::Zilla as I work on them. It’s a huge time saver for me (something I hope to blog about more later). I’ve also implemented some plugins recently: DZP::CheckExtraTests, DZP::BumpVersionFromGit and DZP::Twitter
• I converted the Module::Build repository to git to encourage more contributions and to make it easier to apply them. I released a development version, 0.36_08, with some recent additions.

Here are several other things released to CPAN in the last couple months not mentioned above:

• File-chdir-0.1003 — maintenance release for 5.13.X
• Acme-Module-Build-Tiny-0.04 — a half-serious replacement for Module::Build
• Version-Next-0.001 – increment module version numbers simply and correctly
• ExtUtils-CBuilder-0.2703 — better Windows support for MSVC
• Net-Amazon-Config-0.001 — simple utility to manage Amazon Web Services credentials
• CPAN-Visitor-0.001 — generic traversal of distributions in a local CPAN or minicpan repository
• Capture-Tiny-0.07 — the only output capturing program you should ever need

I unsurprising news, the default Perl 5 object system shows its limits in that you have to think about Perl 5 reference syntax and objects and encapsulation, genericity, abstraction, and polymorphism all at once. Moose encourages people to do the right thing by providing abstractions that encapsulate the concerns of other levels of abstraction. Inside-out objects did something similar.

I realized this yesterday when writing about the state feature introduced in Perl 5.10. If you're a fan of minimalist languages which provide one and only one obvious way to do things, you'll hate this explanation, but at least you'll know why you're wrong.

state declares a lexical variable which maintains its state even after control flow leaves its lexical scope. In other words, these two snippets of code are almost entirely equivalent:

# the closure approach
{
    my $count = 0;

    sub add_user
    {
        my ($user, %data) = @_;
        $data{user_id}    = $count++;
        ...
    }
}

# the state approach
use feature 'state';

sub add_user
{
    state $count      = 0;

    my ($user, %data) = @_;
    $data{user_id}    = $count++;
    ...
}

The one potential difference is that the initialization of $count in the first example must take place before the first call to add_user().

If you're careful to avoid that tiny potential trap, you can achieve the same effect with the closure code. Scheme and Python and even Java fans rejoice for a moment. Okay, that's long enough.

The problem is that—just as with arguing that you don't need fold because you have a for loop with iteration—that line of thinking ignores the fact that the syntactic overhead necessary to make the former example work is too high. Adding a single keyword to achieve the same semantics and avoid that tiny little trap also makes the resulting code more expressive. It's more declarative.

There's nothing wrong with the goal of a language with a minimal feature set. That's a fine goal, but it can't be the most important goal, and it can't be a goal in isolation. That's because sometimes adding a feature lets you remove unnecessary scaffolding.

I believe that it's better to pursue concision than artificial simplicity in program and language design.

The thing about volunteers writing software is that they don't have to do it. The same goes for volunteers writing documentation or reporting bugs or asking questions about how to use or install or configure that software.

The thing about the Perl community is that almost no one gets paid solely for participating in the Perl community. Sure, you can volunteer for a while to earn the cachet and the right to apply for a TPF grant at a fraction of the going consulting rate to justify continuing to work on the unpleasant parts of a project, but you're still effectively a volunteer.

The thing about volunteers is if it's not worth their time or energy or health or sanity or happiness to keep volunteering, they can walk away whenever they want. They have no obligation to continue to do what they do. Not even their sense of devotion or duty or guilt or community camaraderie should compel them to continue on projects that aren't worth their investment of time, and that's more than okay.

The thing about volunteers is that you can't force them to do anything. You can't force them to have your priorities. You can't force them to work to your schedule. You can't force them to work on your project and you can't force them to care about what you care about. They'll do what they want to do when they want to do it and you either deal with it or you don't.

The thing about volunteers is that it's rare to have too many and it's far too common to have far too few. Thus healthy projects spend time and effort recruiting volunteers and keeping volunteers around and guiding the interests and energy and time of volunteers in productive ways, not only by making their projects pleasant and useful but by removing distractions and unpleasantness from their communitites.

The thing about volunteers is that for every one willing to take the abuse and hostility from a few people, you can't tell how many orders of magnitude more potential volunteers find that hostility and abuse so distasteful that they refuse to consider the possibility that it's worth their time to contribute.

The thing about volunteers is that if you allow certain parts of the community to fester and to grow toxic, you're well on your way to having fewer and fewer volunteers who grow more bitter and eventually become a tiny little cluster of angry, angry people who can't do anything productive.

The thing about volunteers is that it doesn't have to be this way.

Certain Perl IRC channels don't have to be seething cauldrons of rage from burned out system administrators who castigate anyone who doesn't know the secret rituals and wordings of arcane rituals to identify themselves as insiders.

Certain Perl forums don't have to devolve into arguments over whose web framework stole which idea from some other place, or whether it's clear that anyone who does or does not use one CPAN dependency or another has parents with specific unpleasant characteristics.

Certain Perl mailing lists don't have to debate whether people who work on one version of Perl or another are hateful fools whose only goal in life is to destroy everything good and sunshiney and organic.

Certain Perl blogs don't have to have comments accusing other volunteers of being liars or thieves or people of negotiable affection because said volunteers disagree on project management styles.

I suppose it's easier to destroy than to create, and it's easier to prove that you're right by demonstrating your scathing verbal wit with a keyboard, and it's easier to believe that you've won an argument if you reduce the other person to a cardboard cutout of simplistic, ridiculous beliefs. It's also easy to justify your decision to spread hostility if you can overlook the fact that the person you're castigating is a human being with complex motivations, goals, dreams, aspirations, beliefs, and emotions.

The thing about volunteers is that they don't owe you a thing.

If you want a Perl community full of hostile people who jump to hasty conclusions, who are willing to nitpick and debate the specific meaning of words than to understand what other people mean, and who are willing to throw wild accusations of crazy, hateful motives around, then you have an easy task. Just say nothing. Let it fester.

Me, I don't think that's the way to encourage a healthy community. After all, how silly is it to argue over how some other volunteer spends his or her time? Yet isn't that what we're doing?

Maybe if more of us speak up when we see this abuse and hostility, maybe we can discourage it. Maybe we can encourage people to try to understand and listen more, or at least to disagree politely if they must disagree. Maybe we can help people unwilling to be civil to find better hobbies than abusing other volunteers. Maybe we can make the Perl community and our IRC channels and our mailing lists and our forums and our comment sections places where potential volunteers want to participate because they know that we appreciate novices and we appreciate volunteers and we don't all have to do the same things or want the same things or agree on the same things to treat each other with respect.

After all, we're all trying to build great software to solve problems. Why should we borrow trouble?

If modern Perl is safer or easier or clearer or simpler or cleaner to write than legacy Perl, then it should be possible to explain how and why to use modern features in lieu of older features.

For example....

Three-argument open()

There are two forms of the open() function in Perl 5. The modern version takes three arguments: the filehandle to open or vivify, the mode of the filehandle, and the name of the file.

The legacy version has two arguments, only the filehandle and the name of the file. The mode of the file comes from the filename; if the filename starts (or ends) with any of several special characters, open() parses them off and uses them.

If you accidentally use a filename with those special characters with the two-arg form of open(), your code will not behave as you expect. This is especially a problem if you're not careful about sanitizing user input, and if any user input ever becomes part of a filename. Consider:

open my $fh, ">$filename" # INSECURE CODE; do not use
    or die "Can't write to '$filename': $!\n";

While this code appears to open $filename for writing, an insecure $filename could start with > to force appending mode, or - to open STDOUT (though I suspect you have to work really hard to force this). Likewise, code without any explicit mode in the second and final parameter is susceptible to any special mode characters.

Extracting file modes into a separate parameter to this function prevents Perl from parsing the filename at all and removes the possibility for this unintentional behavior. As Damian Conway has mentioned, using a separate file mode parameter also makes the intention of the code clearer:

open my $fh, '>', $filename # safer and clearer
    or die "Can't write to '$filename': $!\n";

The modern version of this code is safer and clearer, and it's been available since Perl 5.6.0, released on 22 March 2000. There's no reason not to use the modern version. (If you need your code to run on Perl 5.005, try a core module such as IO::Handle. If you need your code to run on older versions of Perl 5, you have my sympathy.)

I don't even have to use the PAUSE website to upload a new distribution.

In similar fashion, I migrated that distribution to Github. Moritz Lenz had found and fixed a couple of bugs. I'd already set up the distribution such that test cases were reasonably easy to add, and the code was simple enough that the fixes were fairly obvious. Moritz forked my distribution from Gitpan.

I had my own Git clone of that repo, where merging Moritz's changes took a couple of commands. Releasing a new version with those changes was almost immediate. After that, I converted my personal SVK over SVN repository to Git, made my own Git repository on Github, and cherry-picked the commits from my original fork to my new repository.

I never lost history. I never had to edit a conflict. I never had to ask Moritz to resubmit a patch. The only distribution editing I did was to remove unnecessary files from my repository and to ask Dzil to generate them.

I knew all of the existing behavior of my distribution continued to work, because all of the tests passed. I knew my distribution would work properly with PAUSE and the CPAN because all of Dist::Zilla's tests worked. I also know that if any problems arise, the difficulty of fixing them is solely the difficulty of finding and fixing the bugs, not of managing the process of fixing the bug and managing repositories or verifying previous behavior or wrangling uploads or editing metadata in files manually.

The distance between fixing a bug and distributing a new version to users has shortened, and that path is now smoother.

You don't have to use Git or Github or Dzil or Perl. Plenty of other good tools exist to manage complexity or to make complexity go away. Yet isn't that what we should do as programmers? We find barriers and difficulties and obstacles and we eliminate or minimize them, not solely because the new versions have a novelty factor or have greater elegance and aesthetic appeals, but because the relentless process of simplifying removes artificial complexity and structural scaffolding that all too often distracts from the real problems we need to solve.

After all, Moritz and I want to publish an attractive, informative, readable, accurate book about Rakudo Perl 6. Software is just the means by which we do so.

If Perl 5 were to address this problem, someone would have to rethink several well-established, fundamental design and implementation and language decisions. Someone would have to test them, not just with all of the core tests, but with all of the CPAN. Someone would have to document the changes and hope that the updated documentation would eventually make its way into new books on Perl 5 as well as all of the example code on the Internet. Someone would have to update existing code, especially on the CPAN, to take advantage of the new features.

This is all possible. It's happened before. Code people care about gets maintained, and if new features are useful in that code, people will update it to take advantage of new features. Similarly, features removed from a language or library get removed from programs when they update to new versions of that language or library. None of this is new and none of this is surprising.

The real problem in the case of exceptions and scope exit semantics in Perl 5 is that the initial design didn't anticipate the possible edge cases which make the feature (occasionally) unreliable. You can design all of the formal semantics of a language as much as you want. You can spend ten years writing a specification. You can prove the initial implementation with formal methods. Yet as soon as users start doing things you didn't expect, you'll run into cases the specification and design and intent don't cover, and then you have a difficult question.

If someone changed the way scope handling and exit and call stack unwinding worked in Perl 5, such that exceptions could never get lost and lexical destruction always occurred in a predictable order and return values propagated to the appropriate places, Try::Tiny would be unnecessary...

... and someone (probably that same someone) would have to provide a compatibility mechanism for all of the existing code which relies on specific details—documented and otherwise—of scope handling and leave semantics and destruction ordering as it exists in Perl 5.12 right now, to give people time to migrate to the new system and to notify them that the old system is deprecated and to find design and implementation infelicities in the new system.

If reading that paragraph wearies you, imagine how much more doing all of that would be.

Granted, fixing scope handling and destruction ordering and leave semantics is as big a task in Perl 5 (or any language) as anything else. It's doable, from the technical side. Yet how much sixteen year old code needs to change to achieve it, and how many assumptions in the billions of lines of code written in the past sixteen years need to change to make it work? Worse yet, this isn't a Moose situation, where an obvious improvement is available to anyone with a CPAN client and a few minutes to read a tutorial.

I don't mean to dishearten anyone. The edge cases for which Try::Tiny exists are rare, and you can write Perl 5 code for years without encountering them. It's an easy module to use and it shields you from most of the damage.

Even so, fixing bugs the right way—making them impossible to encounter—is not always easy. You don't often get a fresh start in software, but sometimes that's exactly what you need.

It was inevitable to see a suggestion to put Try::Tiny in the core, and the resulting discussion of conflicting goals and motivations and reasons to remove things from the core and suggestions of other things to put in the core was even more inevitable. (If you've read one thread like this before, you've read one too many.)

Yuval Kogman, the author of Try::Tiny responded the other day, saying that Try::Tiny is a band-aid, not a solution.

Here's a design principle.

Exception handling in Perl 5 is difficult to use with complete safety and correctness. You have to beware of a few strange edge conditions that, in most software, never occur. When they do occur, they're strange and difficult because of the semantics of how scopes and exceptions and destruction and call-graph unwinding occur in Perl 5.

Making Try::Tiny a core module—and recommending it as the core-approved way of handling exceptions in Perl 5—enshrines that workaround as well as the flaws of implementation around which it works. The module exists as an alternative to a proper fix at the language and implementation levels. It's a patch. It's a workaround. It's not a controversial extension to the language that some people may want and others don't. Instead, it's a makeshift that offers more safety and correctness and abstractions around those relatively unknown idioms to help people write better programs.

In the same way, signatures is a workaround for the lack of a feature in Perl 5 as much as MooseX::Declare is a workaround for the lack of succinct boilerplate-reducing features in Perl 5.

Making extensions possible doesn't relieve language designers and implementors from the responsibility of providing necessary features and abstractions.

Devel::Declare is, in general, a good thing because it allows experimentation with language features and ideas that may be useful in the core eventually, or may be useful in specific domains, or may be unsuccessful, but at least provide that data. Safety and ease of experimentation help develop communities of invention and evolution.

... but you have to recognize workarounds for what they are. Next time, I'll explain the practical consequences of this tension.