This is part 13 (and the final installment) of an ongoing series where I explore my relationship with Perl.  You may wish to begin at the beginning.

This week we look at what comes next.

I suppose at the end of any long rumination on the past, it’s only natural to think about the future.  I’ve tended to avoid pontificating on Perl’s prospects for a number of reasons, not the least of which is that I don’t have any special knowledge to share.  I’m not an author of Perl books, a contributor to the Perl core, or even a particularly prolific creator or maintainer of CPAN modules.¹  I don’t have any inside knowledge of Perl from hanging out with Larry, or the folks that run the Perl Foundation, or the current Pumpking (nor any past ones, for that matter).  I’m just a regular Joe JAPH—admittedly one who has made his living off Perl for 17 years, well enough to support a nice house in southern California and a complement of five humans, three cats, one guinea pig, and a tank full of tropical fish, snails, and shrimp—but just a working schmoe nonetheless, whose opinion isn’t any better or smarter or wiser or more likely to be true than yours.  So, you should definitely not listen to me.

This is part 12 of an ongoing series where I explore my relationship with Perl.  You may wish to begin at the beginning.

This week we look at how to start putting it all together.

Last week I talked about the trade-offs of DWIM, and wondered if it might be time to try to make sense of all the various parts and perspectives.  Thus, this is the end of the beginning.¹  This is the convergence of all my reminiscences.

Within the past year, I started a new job, again.  This is something that many of us programmers do on a semi-regular basis.²  When you first start a new job, you spend a few days or a few weeks or a few months figuring out what’s going on.  Part of this is learning new concepts, new vocabulary: even if you’re working in an industry you’ve worked in before, every company accretes its own terminology over time, words and ideas that only make sense to the people who work there.  But a big part of it is learning the codebase.  This may have been growing for years—sometimes a decade or more—and it may have been touched by dozens of hands, but still there will be patterns, consistency even in the inconsistencies.  Once you’ve been working there a while, you will know this codebase in a fundamental and almost inexplicable way—there will still be plenty of code in it that you’ve never seen before, but, when you finally do see it, it’ll feel familiar.  Codebases build up character.  It’s not always a good character, but you learn to recognize it, and live with it, and even feel fond of it, in a weird sort of love-hate way.